И снова о массовом Linux'е

Citkit, 18 октября 2007 г

Эта заметка родилась, с одной стороны, как полуответ-полудополнение к Взгляду из ivory tower Владимира Попова. С другой — как следствие чтения многочисленных комментариев к иным статьям (в том числе и не имеющим никакого отношения к «Десктопному Линуксу». Немало материалов к этой теме дают и обсуждения на форумах. С цитаты из одного из таких обсуждений я и начну.

компьютер, который призван облегчать решение различных проблем, пока их не меньше добавляет
© Vityaz, Линуксфорум

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

Так ли это? Давайте не будем лукавить и признаем, что — да, это так. Причем, что интересно, он создает им проблемы вне зависимости от аппаратной платформы и операционной системы на ней: и в Windows, и Linux, и в любой BSD. Даже в DOS'е черном, помнится, создавал. Почему?

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

Это относится к компьютерам вообще. А сфера применения компьютеров, как неоднократно подчеркивал Владимир, неизмеримо шире того ее сегмента, который ассоциируется с этим словом у большинства трудящихся — то есть сегмента настольных персоналок, каковые в настоящее время свелись к архитектуре i386 (PC или, в просторечии, «писюки» - ибо ныне и гордые Mac'и архитектурно являются ничем иным, как «писюками»).

В отличие от Владимира, я не застал героических времен PDP-7 сотоварищи. То есть застать-то застал, но от компьютеров был очень далек. И мое знакомство с продукции IT-индустрии началось с персоналок — IBM PC/XT-совместимых, с процессором Intel 8086/8088, работавших под управлением «черного» DOS'п. Которые я полюбил всей душой. Потому что они позволяли мне сделать (в моей тогдашней профессиональной сфере) то, чего я не мог рассчитать посредством логарифмической линейки, арифмометра - «железного феликса», и даже программируемого калькулятора со встроенным Basic'ом. Причем сделать, не обращаясь во всякого рода ВЦ, каковые обращения требовали немалых бюрократических усилий. Для меня это был чрезвычайно эффективный инструмент работы. А отнюдь не бытовой прибор, создающий удобства.

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

Справедливости ради надо заметить, что вышеуказанные Ваня, Костя или Лёха не забывали и о нуждах Надежды Ивановны или Люси. А также кадровички Нины Егоровны. Они устанавливали на их машины все тот же самый «черный» DOS и программу, необходимую для соответствующей работы — бухучета, учета кадров (тогда их не сочинял только ленивый). Ну а для Люси — разумеется, Lexicon. И писали простенький batch-файл, позволяющий запустить эту программу нажатием одной клавиши.

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

А потом произошло классовое расслоение. Ваня, Костя и Лёха постепенно мигрировали на Linux — потому, что там они свою работу могли выполнять намного эффективней, чем в «черном» DOS'е или на PDP-7. Подчеркну при этом, что они были и оставались самыми обычными пользователями. А вот Надежда Александровна, Нина Егоровна и Люся почему-то стали работать в Windows — причем отнюдь не по собственному желанию. И вi думаете, как говорят в Одессе, эффективность их работы повысилась? Фиг с маслом — ответит вам любой одессит (конечно, немножко другими словами). Ибо у них тут же появилось множество новых забот: как им слушать музыку, смотреть кино, ставить и запускать новые игрушки. И выяснять, почему после установки очередной игрушки их система развались напрочь. Разумеется, работа при этом не делалась ни лучше, ни быстрее.

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

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

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

Маленький Post Scriptum

Я заранее предвижу все возможные комментарии на это сочинение:

и про то, что компьютер действительно стал бытовым прибором;

и про драйверы, изобилия которых не добиться без того, что Linux станет массовой системой;

и про вселенскую угрозу, исходящую от монополии Microsoft;

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

И ответы на них были даны столь же давно — как в публикациях моих коллег и единомышленников, так даже и в моих. Ответы, для нас вполне весомые, хотя и не универсальные.

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

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

Post Post Scriptum

Эта заметка в целом была написана, когда я ознакомился с мнением Trueash'ша, высказанном им на своем блоге (http://trueash.livejournal.com/) в развитие цитировавшегося в статье Владимира поста. Не скажу, что оно заставило меня изменить свое — но внимания безусловно заслуживает. Думаю, история эта будет иметь продолжение...

Linux и файловые системы: еще раз о проблеме выбора

Citkit, 15 марта 2007 г

Весна наступила... Индо взопрели озимые, солнышко рассупонилось. Старик Ромуальдыч начал к своей портянке принюхиваться - оттаяла, видать. Податтаяли и пользователи - на форумы потянулись, вопросы задавать, да ответы получать...

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

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

В качестве "родных" для Linux (то есть тех, на которые он может быть установлен и с которых способен стартовать) рассматриваются следующие файловые системы: ext2fs, ext3fs, ReiserFS, XFS, JFS. Именно они обычно и предлагаются на выбор при установке подавляющего большинства дистрибутивов. Конечно, существуют и способы установки Linux на файловые системы FAT/VFAT/FAT32, но это - только для тех медам и мсье, которые понимают толк в извращениях, и о них я говорить не буду.

Исключу из рассмотрения также JFS - по следующим причинам:

• малой распространенности среди пользователей Linux;
• недостаточности источников информации по ней (именно в Linux - для родной ОС AIX эта файловая система прекрасно документирована);
• моим лично слабым с ней знакомством.

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

Начну рассмотрение с ReiserFS - потому что поводом к сочинению этой заметки послужил вопрос: а что следует считать маленькими файлами? Ведь общеизвестно, что именно эффективность работы с мелкими файлами является сильной стороной этой файловой системы.

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

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

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

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

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

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

По суммарному быстродействию ReiserFS однозначно быстрее всех остальных журналируемых FS, а по некоторым показателям превосходит и ext2. С результатами сравнения скорости выполнения некоторых распространенных файловых файловых операций можно ознакомиться здесь.

А вот с совместимостью у ReiserFS дело обстоит несколько хуже. Доступ к ней из ОС семейства Windows, насколько мне известно, невозможен. В некоторых операционках семейства BSD (DragonFlyBSD, FreeBSD) реализована поддержка этой файловой системы, но в режиме только для чтения. Даже вероятность того, что произвольный Linux LiveCD прошлых лет не имеет поддержку ReiserFS, не нулевая.

И тут впору вспомнить об ext3fs. Преимущество ее вовсе не в большей надежности - это такая же легенда, как и неустойчивость ReiserFS. О случаях краха ext3fs я слышал не меньше, чем об аналогичных происшествиях с ReiserFS. Самому мне не удавалось порушить ни ту, ни другую. Разве что с ext2 получалось - но и то очень давно, во времена ядра 2.2 (или даже еще 2.0).

Нет, главное преимущество ext3fs в ее совместимости - она с гарантией будет прочитана любой Linux-системой. Например, при восстановлении с какого-нибудь древнего подручного LiveCD - ситуация, практически не столь уж невероятная, мне приходилось в нее попадать. Опять же, большинство BSD-систем легко понимают ext3fs (хотя и без журналирования). Для Windows также имеются, насколько я знаю, всякого рода драйверы и plug-ins к распространенным файловым менеджерам (типа Total Commander), обеспечивающие доступ к разделам с ext2fs/ext3fs.

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

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

Относительно XFS можно сказать следующее. В плане совместимости к ней относится все то же самое, что написано для ReiserFS - более того, до некоторого времени она не поддерживалась стандартным ядром Linux. С точки зрения быстродействия она XFS она также не блещет, выступая суммарно примерно на одном уровне с ext3fs. А на операции удаления файлов вообще демонстрирует удручающую медлительность.

По моим наблюдениям, использование XFS оправдывает себя при работе не просто с большими, а с очень большими файлами - каковыми являются фактически только образы DVD и видеофайлы.

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

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

Если предусматривается отдельный раздел под каталог /boot (а это рекомендуется при использовании загрузчика GRUB его разработчиками) - для него никакая другая файловая система, кроме ext2fs, не оправданна, какое-либо журналирование тут смысла не имеет. Наконец, если создается отдельный раздел под всякого рода мультимедийные материалы - тут можно подумать и о XFS.

О prelink: предварительное связывание как способ повышения быстродействия

Citkit, 4 октября 2005 г

Один из резервов верховного главнокомандования в деле повышения быстродействия Linux-системы - механизм предварительного связывания или, по простому, прелинкинга (prelinking).

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

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

Для операции прелинкинга необходимы:

• дистрибутив Linux с достаточно свежими версиями главной системной библиотеки glibc (версии 2.3.1 и выше) и сборочного комплекта binutils (версии 2.13 и выше); последний пакет рекомендуется в исполнении www.kernel.org, хотя я использовал и вариант с www.gnu.org - также без всяких проблем;
• библиотека libelf версии 0.7.0 или, лучше, 0.8.2; если оной не имеется - берется она здесь: http://www.stud.uni-hannover.de/~michael/software/;
• собственно программа prelink, имеющая местом своего проживания ftp://people.redhat.com/jakub/prelink.

Для начала устанавливаем libelf - обычным образом, распаковав архив и запустив последовательно ./configure, make, make install. Затем пытаемся проделать ту же процедуру с prelink - и в ходе исполнения make благополучным образом получаем сообщение об ошибке, причем, что самое обидное и парадоксальное - на стадии сборки компонентов для архитектуры PPC, нужной нам, как зайцу стоп-сигнал. Я довольно долго ломал голову, как побороть эту напасть, пока в недрах дерева портежей Gentoo не обнаружил специально предназначенный к тому патч. Он залегает в отростке portage/sys-devel/prelink/files и носит имя prelink-20030505-glibc231.patch (к сожалению, более простого способа его получения я не обнаружил - разве что самому написать). Несовпадение номеров версий патча и собственно prelink смущать тут не должно - все описанное проверено на собственной шкуре и работает.

Итак, распаковываем архив prelink, переходим в образовавшийся каталог и налагаем патч:

$ patch -Np1 -i /path/prelink-20030505-glibc231.patch

Теперь можно безбоязненно запускать ./configure, make, make install - все пройдет нормально. В результате мы получаем исполняемый файл /usr/local/sbin (если, конечно, при конфигурировании не был задан другой префикс - логичным представляется использование --prefix=/usr/sbin).

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

Прежде чем запускать программу связывания, необходимо выполнить некоторые конфигурационные мероприятия. А именно - скопировать из каталога doc в дереве исходников prelink файл prelink.conf:

$ cp /path_to_prelink-src/doc/prelink.conf /etc

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

-l /bin
-l /usr/bin
-l /sbin
-l /usr/sbin
-l /usr/X11R6/bin
...
-l /lib
-l /usr/lib
-l /usr/X11R6/lib
...

Пользователям KDE (а именно к ним, как и к пользователям GNOME, в первую голову обращен этот раздел заметки) следует проследить, чтобы в этом описании файла /etc/prelink.conf присутствовали пути к библиотекам Qt, kdelibs и исполнимым файлам kde, каковыми при ручной сборке по умолчанию являются:

...
-l /usr/local/kde/bin
-l /usr/local/qt/bin
...
-l /usr/local/qt/lib
-l /usr/local/kde/lib

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

Теперь можно, наконец, запустить процесс предварительного связывания. Делается это так:

prelink -avfmR

Смысл опций команды следующий: -a предписывает применить прелинкинг ко всем исполняемым файлам; -v - выводит подробную информацию о ходе процесса - необходимость этого я покажу парой строк ниже; -f - директива применять прелинкинг повторно, даже если эта процедура уже была выполнена (необходимость этого также будет обоснована чуть позже); -m и -R - опции, страхующие от ошибок нехватки памяти и переполнения буфера (подробности, как обычно, - на man prelink).

После этого начинается собственно предварительное связывание, - процесс во времени длящийся, хотя и не столь уж долго - моя машина управляется с ним за время, затрачиваемое на выкуривание сигареты). Однако в ходе его может начаться самый охмуреж: вывод сообщений (обеспечиваемый нам опцией -v, так что без нее не обойтись), что программа имя_рек собрана с опцией non-fPIC и потому прелинкована быть не может. У меня в дистрибутиве CRUX, установленном из прекомпилировыанных пакетов, в этот черный список попали все приложения KDE и некоторая, зато самая тяжелая, часть Иксовых. То есть именно те софтины, ради ускорения которых все и затевалось.

Выход тут, к сожалению, один, простой, но занудный: пересобрать все, что попало в список. И тут уж, разумеется, впредь не забывать, что любая программа, в выводе ./configure --help которой отмечается доступность опции --with-pic, должна конфигурироваться именно с ее участием (флаг -fPIC можно добавить в и список значений переменной CFLAGS). А после этого - повторить процедуру прелинкинга, уже - с неизменно превосходным результатом.

Да, пора поговорить о том, насколько этот результат превосходен (и стоит ли игра свеч вообще). Должен заметить, что первый мой опыт был несколько обескураживающим. Конечно, скорость первой загрузки приложений увеличилась - но далеко не в той степени, как было обещано на http://www.gentoo.org (а там угрожали примерно 50-процентным ускорением загрузки KDE и ее приложений). Однако повторение эксперимента (уже на базе CRUX) положение существенно выправило.

Я очень люблю некоторые KDE-приложения - в частности, konqueror, который отношу к числу лучших софтин всех времен и народов, и по долгу службы вынужден использовать некоторые KDE-приложения, аналогов в мире Open Sources не имеющие (например, kdem - программу визуализации данных цифровой картографии в одноименном формате). Так вот, меня всегда страшно раздражало то, как долго эти считанные приложения загружаются - ибо вслед за собой затягивают в память чуть не всю Qt с kdelibs (благо, еще не коран с шариатом, книгой тариката и всеми другими книгами).

Это было до прелинкинга. Что же стало после? На загрузку konqueror уходят неуловимые мгновения, kmail - аналогично, koffice - с OpenOffice даже смешно сравнивать, и так далее. Для пробы запустил саму KDE - время загрузки сопоставимо с оконными менеджерами средней степени тяжести (типа WindowMaker). Короче говоря, используйте прелинкинг - и будет вам счастье...

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

На использование предварительного связывания накладываются некоторые ограничения. Так, после выполнения тотального прелинкинга могут отказаться работать программы, статически связанные с прелинкованными библиотеками. Благо, в нормальной Linux-системе таких или крайне мало, или нет вообще. И к тому же отказ их - отнюдь не обязателен. Так, я использую обычно текстовый редактор Nedit, статически слинкованный с библиотекой Lesstif. Так вот, хотя мой Lesstif перечислен в списке путей прелинкинга, никаких аномалий в работе Nedit'а не обнаруживается - он функционирует вполне справно.

Далее, предварительное связывание не может распространяться на бинарные файлы проприетарного происхождения, для которых исходники недоступны. Однако это обходится совсем просто: достаточно проследить, чтобы такие программы (а у меня в их числе - единственный RealPlayer, да и то лишь потому, что ни лучшего Алмазова, ни Алешковского не могу найти в человеческом формате) устанавливались бы в каталог /opt (что, к слову сказать, они обычно и делают). А каталог этот, понятно, не включать в описание путей в файле /etc/prelink.conf.

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

Linux: приключения с VPN микрорайонного масштаба

Citkit, 18 апреля 2006 г

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

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

Конечно, в качестве почти универсального (для Москвы) варианта оставался Стримм - но от них я очень долго не мог получить ответа на запрос о пригодности моей телефонной линии (надо сказать, что у соседей по подъезду Стримм работал вполне успешно).

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

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

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

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

Дело в том, что ни на одной моей машине уже в течении многих лет нет никакого намека на Windows. А есть лишь Linux или (иногда - и) какая-либо из BSD-систем. В частности, в тот момент (и по сию пору) стоял на ней Linux Kubuntu Dapper (5-я пре-релизная версия). А вот как подключать его к сети - провайдеры не имели ни малейшего представления. И даже задали вопрос - а почему бы мне не поставить Windows для подключения к Инету? На что я резонно ответил, что, подобно той даме, что в раннеперестроечные времена написала известную статью в журнале "Огонек", принципами не поступаюсь. И скорее готов отказаться от услуг провайдера, не способного обеспечить в своей сети работу машины под свободной операционкой.

Дело осложнялось тем, что никакого DHCP-сервера у провайдера не имелось - внутрисетевые IP выдавались статически. А имелась зато авторизация по VPN, снискавшая уже нежную "любовь" среди линуксоидов. И в адрес которой я на Linux-форумах слышал много слов (все больше нежных и ласковых, исконно русских, от бороны, что называется).

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

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

• внутрисетевой IP-адрес;
• маску подсети;
• IP-адреса шлюза, 1-го и 2-го DNS;
• имя (не адрес) VPN-сервера - внутреннее, в форме труляля.ok;
• пароль и логин для авторизации на нем;
• прочие мелочи, вроде URL интранет-сервера (с характерным именем www.ok), страницы личной статистики, и так далее.

Очевидно, что для начала следовало настроить доступ к внутренней сети провайдера. Сделать это в моих условиях трояко: руками из командной строки, текстовым редактором через конфигурационные файлы и автоматически - средствами администрирования Kubuntu (точнее, средствами, которые Kubuntu заимствовала от своего умолчального десктопа - KDE).

Чисто ручной способ сводится к вводу команды ifconfig с указанием имени сетевого интерфейса (в данном случае - eth0), собственного IP-адреса и маски подсети. На нем я задерживаться не буду - детали можно посмотреть в man ifconfig.

Для ручной настройки достаточно было вписать в файл /etc/network/interfaces (напоминаю - речь идет о Kubuntu, то есть с точки зрения конфигурирования, практически о Debian - в более иных дистрибутивах потребовалось бы править другие конфиги) строки следующего вида:

# Указание на статически внутрисетевой IP
iface eth0 inet static
# Собственно внутрисетевой IP
address
# Полученная от провайдера маска подсети
# В большинстве случаев она именно такова
netmask 255.255.255.0
# IP-адрес шлюза
gateway
# IP-адреса 1-го и 2-го сервера имен, через пробел
dns-nameservers

# Предписание запускать сетевую службу при старте машины
auto eth0

Наконец, автоматизированный метод - это вызов через K-меню KDE пункта System Setting, и выбор в секции Сеть и Интернет иконки Настройка сети. Этот метод применим для всех пользователей KDE - разве что в других дистрибутивах понадобится вызывать KCC (KDE Control Center), а уж в нем отыскивать, где настраивается сеть.

Но в принципе ничего сложного тут нет. Посредством соответствующей кнопки нужно перейти в режим администратора, введя пароль (обычного пользователя - в Kubuntu, root'а - в большинстве прочих дистрибутивов. Далее из списка на первой вкладке (Network Interfaces) выбирается нужный интерфейс (скорее всего, eth0 - рис. 1), щелчок на нем правой клавишей вызывает контекстное меню, в котором следует указать пункт Configure interface. А затем в появившейся панели остается только вбить полученные от провайдера свой IP'шник, сетевую маску и Gateway (он же шлюз - рис. 2). После чего, перейдя на вкладку Domain Name Systen, последовательно добавить адреса первичного и вторичного DNS-серверов.

Рис. 1. Выбор сетевого интерфейса...

Рис. 2. ...и его конфигурирование

Проверка правильности настройки сети осуществляется в три этапа. Сначала командой

$ ifconfig eth0

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

$ ping www.ok

пропинговываем интранет-сервер провайдера. И, наконец, заходим на этот самый интранет-сайт через браузер, указав в его адресной строке URL - www.ok.

Я проделал все эти действия успешно, в результате чего получил доступ к внутреннему FTP-серверу (не буду говорить о его содержании). Но ни малейшего Интернета, разумеется, не было. Так что настала пора переходить к снастройке VPN-подключения.

Это дело требует в первую очередь поддержки протокола PPTP (Point-to-Point Tunneling Protocol). Клиентская его часть (а большего в данном случае и не требуется) обеспечивается пакетом, который в deb-клонах носит название pptp-linux. Авторское его имя, кажется, - linux-pptp, во FreeBSD он зовется pptp-client, в других системах и дистрибутивах возможны и иные имена - в каждом конкретном случае это следует уточнить штатными средствами системы пакетного менеджмента.

Впрочем, пакет этот вовсе и не обязан присутствовать в произвольном дистрибутиве. Так, в репозитории Archlinux я его не обнаружил. Так что пользователям этого дистрибутива придется начинать настройку VPN с ручной сборки linux-pptp (или написания build-файла для его построения).

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

Depends: libc6 (>= 2.3.4-1), ppp (>= 2.4.2)

каковые и так имели место быть установленными. Так что, выполнив

$ dpkg -i /media/cdrom/pool/main/p/pptp-linux

я легко получил поддержку искомого протокола. А дальше, как обычно бывает в Linux'е, "средь мира дольного, для сердца вольного", лежали "два пути". Правда, в данном случае их оказалось целых три:

• загрузить pptp руками из командной строки;
• использовать скрипт для установки VPN-соединения;
• прибегнуть к какому-либо front-rnd-конфигуратору.

От "ручного запуска" я отказался - да это и не решение задачи, каждый раз запускать pptp руками. Обратившись по началу к напрашивающемуся варианту - скриптовому запуску. И надо заметить, что скриптов для этого дела в сети можно раскопать немало. Например, решение, претендующее на универсальность, описано на POSIX.ru. Вариант для Gentoo имеет место быть на Линуксфоруме. А при необходимости находится и очень внятное пошаговое описание процедуры не где-нибудь, а в Debian (на сей предмет есть и еще одно руководство - правда, на английском). Да и на форумах нашей тематики тема эта была жевана-пережевана. В общем, казалось бы, недостатка в информации не предвиделось.

Ан не тут-то было. Ни один из найденных мной скриптов "в лоб", после соответствующей коррекции реалий, не заработал. Причем ситуация была самая скверная: нельзя сказать, что они не работали вообще (сообщений об ошибках не поступало), но и назвать это работой язык не поворачивался. А именно: VPN-соединение после отработки, например, специально Debian'овского скрипта устанавливалось. Это можно было видеть и через ps (соответствующие процессы в списке присутствовали), и через ifconfig -a, который показывал появление интерфейса ppp0. Но держалось оно считанные мгновения, не позволявшие даже запустить команду ping. Однако из этого следовал и позитивный вывод - видимо, что-то не так в консерватории, то есть в параметрах, данных провайдером. Как станет ясным из дальнейших событий, так оно и оказалось.

Оставалась последняя надежда - автоматический конфигуратор. Таковой поначалу обнаружился в единственном числе, выступая под именем pptpconfig. В репозитории Ubuntu его не оказалось, но на авторской странице можно, кроме исходников и rpm'ок, найти также и deb-пакеты, причем вместе с основными зависимостями - php-pcntl и php-gtk-pcntl. Правда, последние тянут за собой рекурсивно зависимости собственные. Тем не менее, с помощью модема, dpkg и чьей-то матери задача установки pptpconfig решаема. По крайней мере, мне это сделать удалось.

Обращение с pptpconfig достаточно подробно описано на сайте http://pptpclient.sourceforge.net, а также, как ни странно, на интранет-сайте моего провайдера (на примере Mandrake и Suse).

И так, pptpconfig запускается с правами администратора, то есть в Ubuntu/Kubuntu так:

$ sudo pptpconfig

После чего перед глазами появляется следующее окно (рис. 3).

Рис. 3. Создание туннеля

В соответствующие поля формы вбиваем имя туннеля (то есть соединения - в моем случае оно могло быть произвольным набором символов), IP'адрес VPN-сервера (говорят, что можно и его внутрисетевое имя, но у меня это не сработало), полученные от провайдера логин и пароль (поле Domain остается пустым).

Откуда взялся адрес VPN-сервера? Ведь, как вы помните, провайдер оставил мне в конвертике только его внутрисетевое имя. Определит адрес по URL можно различными путями, я воспользовался командой

$ host труляля.ok

каковая и выдала мне искомый IP'шник.

Заполнив таким образом форму Server, я, в соответствие с инструкциями, перешел на закладку Encryption, где, вместо отмеченного по умолчанию пункта MPPE, включил пункт, говорящий про EAP (рис. 4).

Рис. 4. Настройка Encryption

Теперь остается только кнопкой Add добавить новосозданный туннель в список и, отметив его курсором, нажать кнопку Start для проверки. Нажатие ее приводит к открытию нового окна (рис. 5), в котором проверку можно выполнить посредством кнопки Ping.

Рис. 5. Окно статуса соединения VPN

К моей радости, пинги с новым внутренним сервером прошли успешно. Более того, команда

$ ifconfig -a

показала наличие интерфейса ppp0 (никуда теперь не исчезающего) с новыми параметрами - моим IP-адресом (прежний, для eth0, начинался со 192, этот же - со 172), адресом P-t-P (он, собственно, и пинговался при тесте) и новой маской подсети.

Теперь, в соответствие с инструкцией, оставалось последнее действие: сделать только что созданный канал доступным для программ. Для этого останавливаю соединение (кнопкой Stop в любом из двух окон) и в окне настройки перехожу на вкладку Routing, включаю в ней пункт All to Tunnel вместо умолчального Client to Lan (рис. 6) и кнопкой Start активизирую туннель заново. Теоретически после этого можно, например, выйти в Интернет любым браузером.

Рис. 6. Делаем канал доступным

В этот момент радость моя и закончилась. Попытки открыть какой-либо сайт успехом не увенчались. Пинги не проходили ни на один внешний URL. Более того, и внутрисетевые URL'ы пинговаться перестали.

Так и пребывал бы я в растерянности, если бы не советы знакомых админов - пропинговать внешние сервера не по URL, а по IP-адресам. И - о чудо - пинги пошли. Стало ясно, что дело в настройках DNS. просмотр файла /etc/resolv.conf показал, что вместо прежних их адресов появились новые - совершенно мифического облика. Ничтоже сумняшеся, я вписываю туда IP своего служебного DNS-сервера. После чего наконец обретаю выход в Интернет.

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

Рис. 7. Указание DNS-сервера

Теоретически узнать IP сервера имен можно было бы, вероятно, спросить у провайдера непосредственно. Однако дело происходит в выходные дни, и попытки дозвониться до их службы техподдержки успехом не увенчались. А ждать до понедельника - терпения не хватало. И тогда я, временно оставив DNS с моей службы, прибег к команде nslookup. Данная с аргументом - доменным именем, она выводит как адрес используемого сервера имен, так и реальный IP, к которому это имя привязано:

$ nslookup name.ru
Server:  IP
Address: IP#port

Name:   name.ru
Address: IP

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

Правда, пока для этого требуется не только вызвать pptpconfig из командной строки терминала через sudo, но и запустить собственно соединение кнопкой Start. Что не то чтобы обременительно - но создает чувство некоторого дискомфорта, заствляя вспомнить старое, но недоброе модемное время.

Вторая проблема устраняется легко. В окне конфигуратора нужно перейти к закладке Miscellaneous, в которой включить пункт Start tunnel when this programm starts и, на всякий пожарный случай, Reconnect is disconnected (рис. 8, смысл, думаю, понятен без перевода).

Рис. 8. Запуск туннеля одновременно с запуском pptpconfig

Решения первой задачи я пока не нашел. Вследствие особенностей дистрибутивов Kununtu (отсутствия root-аккаунта как такового) со стандартными средствами типа запуска от имени другого пользователя, у меня ничего не вышло. Придется думать дальше. Ну и если кто подскажет - буду весьма признателен.

Какой вывод можно сделать из моей истории? Перефразируя слова Александра Дюма, заключаю: не следует верить ни тому, что говорят провайдеры, ни тому, что говорят их враги. Соединение VPN в Linux наладить вполне можно. Нужно только, если это не получается с первой же попытки, затратить некоторое время на перебор вариантов. Используя прямые IP, не полагаясь на данные, полученные при подключении.

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

Кстати говоря, описанный метод настройки VPN - далеко не единственный. Прошерстив через

$ apt-cache search vpn

репозитории Ubuntu (с чего, собственно, и нужно было бы начать по хорошему, если бы не нетерпеливое вожделение Сети), я обнаружил несколько VPN-клиентов и немало front-end'ов для них, например - kvpnc, предназначенный, как явствует из имени, специально для KDE. И, следовательно, более подходящий для использования в Kubuntu. Возможно, что с какими-то из этих программ результата можно было бы добиться быстрее и проще. Впрочем, этот вопрос я надеюсь исследовать и описать в ближайшее время.

Автор выражает признательность Игорю Борейко, системному администратору Геологического института РАН, и Стену, админу сайта http://posix.ru, за ценные советы и моральную поддержку.

Ками-терминал, или как "бархатно" уползти от "окон"

Citkit, 6 июня 2006 г

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

Время от времени на всяческих форумах, имеющих отношение к Linux и Open Source вообще, раздаются пламенные призывы: "Даешь Linux в корпоративе!" и им подобные. Правда, при ближайшем рассмотрении обычно оказывается, что авторы таких призывов подразумевают примерно следующее: "Ребята, бросайте свои дела и сделайте так, чтобы я мог зарабатывать на Linux". Никаких реальных действий за такими призывами, как правило, не стоит.

Тем не менее, корпоративные решения на базе Linux и Open Source на Руси (сиречь в России и Украине) существуют. Просто они а) не очень афишируются их разработчиками, и б) используются в достаточно специфических сферах человеческой деятельности. На первом факторе заострять внимание не буду (sapienti sat, как говаривали древнегреческие римляне). А вот причины второго явления рассмотрения заслуживают.

Действительно, любой современный дистрибутив Linux общего назначения (и даже, скажем, такая ОС, как FreeBSD) содержат в своем составе почти все, что необходимо для организации внутрикорпоративного документооборота и коммуникаций с внешним миром. За двумя важными исключениями: средств векторной графики (и, особенно, CAD-систем) и ведения финансовой документации. Если первый фактор играет роль лишь в отдельных случаях (далеко не все фирмы и организации испытавают необходимость в векторных "рисовалках" и, тем более, системах автоматического проектирования), то без бухгалтерского учета и сопряженных с ним материй, как без воды - "ни туды и ни сюды). А когда мы говорим слова "бухгалтерский учет", под ними молчаливо подразумевается продукция фирмы 1C - так уж исторически сложилось в Государстве Российском. А продукция эта, как известно, функционирует исключительно под одной операционной системой - и вы знаете, под какой. Так что получается, что и "без винды, как без воды"...

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

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

Другой путь использования Windows-софта в среде Linux - запуск его под эмуляторами, типа WINE. Правда, именно для прдукции 1C, защищаемой аппаратными ключами, это сопряжено с определенными трудностями (эмуляторы реагируют на аппаратные ключи весьма неадекватно), но, насколько мне извсестно, трудности эти преодолимы - примером чему разработки фирмы Этерсофт (http://etersoft.ru/). Однако и WINE не избавляет от необходимости лицензий - теперь уже только на приложения, но все равно в количестве рабочих мест.

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

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

А вот предлагаемые фирмой Kami аппаратные решения с клиентской стороны (то есть собственно терминалы) заслуживают отдельного разговора. Это - классические "тонкие клиенты", то есть машины на базе материнских плат формата ITX с процессорами VIA (в ряде случаев не требующих активного охлаждения). Собственных средств хранения информации они не имеют, но снабжены внутренними винчестероподобными носителями, призванными обеспечить загрузку системы и подключение ее к сети. Впрочем, это можно проделать и с обычного флэш-драйва, подключаемого к USB-разъему.

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

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

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

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

А вот в качестве серверной ОС может выступать практически любой дистрибутив Linux (ALT, ASP, RedHat EL, SuSE etc - есть крамольная мысль, а не прикрутить ли туда какую-либо из BSD-систем?), куда спокойно "укладывается" серверная часть предлагаемого решения или в виде RPM-пакетов, или из тарболла. В результате могло бы получиться забавно - зоопарк "железа", наложенный на зоопарк софта, в том числе и системного. И потому разработчиками принято унифицирующее решение - использовать на серверной стороне Red Hat Enterprise Linux, как он нынче официально называется (сокращенно RHEL). Цель чего - оградить пользователей от всех "радостей" разнообразия интерфейсов. Ибо теперь интерфейс их рабочего стола предоставляется серверной стороной (о чем - чуть ниже).

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

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

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

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

Системное меню позволяет запустить с терминала пользовательские сеансы различных типов доступа к Linux- и Windows-системам (сами они исполняются, разумеется на сервере). Так, работа в среде Linux возможна через клиенты OpenSSH, X11 и VNC. Первый обеспечивает авторизацию пользователя на сервере (разумеется, для этого соответствующий аккаунт должен быть там создан администратором) по одноименному защищенному (шифруемому) протоколу и дальнейшую работу в режиме командной строки - практически также, как на виртуальной консоли обоычной персоналки. Однако основная задача SSH-клиента - запуск на рабочем столе пользователя графических приложений (браузер, почтовый клиент и т.п.), "завернутых" в страхующу SSH-обертку. Причем это делается администратором прозрачно для пользователя (с помощью ключей авторизации), и не требует ради отдельного приложения "тащить" на терминал отдельную сессию Linux.

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

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

Ну а сеанс VNC - это запуск cистемы удаленного доступа к компьютеру (сиречь обратно же нашему серверу), использующей специальный протокол RFB (Remote FrameBuffer). Каковой обеспечивае передачу клавиатурных и "мышиных" манипуляций с терминала на сервер и вызванных ими обновлений экрана - в обратном направлении по сети. Подобно Иксовому сеансу, он отображается в графическом режиме, однако может быть запущен не только в полноэкранном режиме, но и в окне приложений.

В общем, пользователь Linux (или любой другой Unix-подобной системы), сев за Ками-терминал, не обнаружит для себя ничего неожиданного или непривычного. Кроме одного: параллельно с любым из перечисленных выше Linux-сеансов он может запустить еще и сеанс работы с Windows - и, более того, свободно переключаться между ними посредством своеобычной комбинации клавиш Alt+Control+F#.

Открыть Windows-сессию можно двумя способами - посредством Citrix-клиента и клиента RDP. К сожалению, разницы между ними объяснить не могу, так как, подобно д'Артаньяну, забыл о Windows даже то, чего не знал... Однако с точки зрения пользователя в любом случае это будет выглядеть также, как пользовательский сеанс в Windows XP на локальной машине. В котором можно открывать любые Windows-приложения, включая сакраментальные программы бухгалтерского учета и прочей бюрократии. Причем для этого достаточно иметь всего одну копию и самой ОС, и требуемых под нее софтин - ибо все это хозяйство все равно исполняется на сервере.

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

И в заключение: обсудить эту статью (и сам терминальный комплекс) можно в соответствующем трейде на форуме http://posix.ru. Ну и его непосредственный разработчик не откажет в дополнительной информации - с ним можно связаться так: leux@yandex.ru.

Кратко о udev

Citkit, 23 августа 2005 г

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

Однако любой прогресс - штука неоднозначная, и чем-то за него расплачиваться приходится. В данном случае первый счет был предъявлен в виде крайне неуклюжей системы наименования устройств: вместо простого и понятного /dev/hda1 для первого раздела на первом физическом диске мы получили жутковатые конструкции типа /dev/ide/host0/bus0/target0/lun0/part1. И даже механизм символических ссылок вроде /dev/discs/disc0/part1 (что являет собой симлинк на вышеуказанный адрес) не очень облегчил дело. А реализация обратной совместимости именования устройств через соответствующего демона - devfsd - требовала дополнительных телодвижений (не для всех устройств - абсолютно тривиальных), да и загромождает каталог /dev до невозможности восприятия. Как тут было не позавидовать пользователям FreeBSD 5-й ветки, которые, в силу ряда причин, обратной совместимостью могли не заморачиваться. И где все содержимое каталога /dev умещается на половине стандартной консольной страницы...

Были и некоторые иные неудобства в Linux-реализации devfs. В частности, меня больше всего доставало следующее. Как известно, в POSIX-системах большинство накопителей с интерфейсами, не являющимися нормальным IDE (ATAPI), предстают перед пользователем через девайс ass (пардон, scsi, конечно же). В частности - те же USB-флэшки, которыми я пользуюсь постоянно. И причем, в силу специфики работы, вынужден их постоянно менять.

Что происходит в этом случае? Воткнув флэшку первый раз, мы видим в файловой систем устройств появление нового файла - /dev/scsi/тра_та_та/disc. Или, в зависимости от схемы разбиения, то же самое с окончанием на part1 или part4 (почему всякого рода сменные накопители, начиная с zip-дисков, фабрично часто разбиваются как 4-й primary partition - тайна сия велика есть).

Разумеется, истинный POSIX'ивист, закосневший в смертном грехе лености, быстро избавит себя от необходимости набора столь длинного пути при монтировании флэшки. Внеся в файл /etc/fstab строку типа

/dev/scsi/host0/bus0/target0/lun0/disc /mnt/usb \
vfat user,noauto,umask=022 0 0

или, в предположении, что вкрученный винчестер у него один,

/dev/discs/disc1/disc /mnt/usb vfat \
user,noauto,umask=022 0 0

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

...До того, правда, момента, как не потребуется ему эту флэшку вынуть и вставить другую (да хотя бы и ту же самую). Каковая тут же волшебным образом превратится в устройство с именем /dev/discs/disc2/disc, и попытка смонтировать его тем же образом закончится сообщением об отсутствии такого устройства в /etc/fstab или /etc/mtab. Конечно, ручному монтированию это не помешает, но придется а) проводить его уже от лица root'а и б) маску доступа впечатывать с клавиатуры.

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

Что такое udev? Человеческим языком выразить затрудняюсь. Могу только процитировать соответствующее определение с man-страницы в своем вольном переводе. Так вот, согласно man (8) udev, это - поддержка настраиваемого динамического именования устройств в Linux (насколько я знаю, в других Unix-like ОС такого понятия до сих пор не было, за BSD-системы могу говорить определенно).

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

Правда, для своего функционирования udev нуждается в еще одной виртуальной файловой системе - sysfs, но ее поддержка в ядрах серии 2.6.X осуществляется автоматически (а сама эта файловая система монтируется по умолчанию в каталог /sys). Основываясь на информации из которой, udev и присваивает имена всяческим устройствам (в том числе и при горячем их подключении).

Как известно, любой POSIX-системе имена конкретных устройств более или менее безразличны, так как оперирует она не с ними, а с их идентификаторами. Ранее, до внедрения devfs (и, тем более, udev), в качестве таковых выступали т.н. старший номер устройства, определяющий класс оных (например, ide-накопители) и младший его номер, указывающий на конкретный экземпляр данного представителя класса. Ныне же в ход пошли непосредственные идентификаторы устройств - - сериальный номер винчестера, его положение на канале IDE-шины, и так далее, сочетание которых для каждого диска (раздела, и так далее) оказывается уникальным. Так вот, udev извлекает эти сведения из файловой системы sysfs и, руководствуясь определенными правилами, ставит им в соответствие "человеческие" имена (вроде тех же /dev/hda и так далее).

В двух предыдущих абзацах я в меру своего разумения пересказал прочитанное - в частности, в Udev FAQ с kernel.org. И, возможно, пересказал не вполне понятно. Вот и я мало чего из прочитанного понял, пока не поставил себе udev. Благо, процесс этот очень прост и сводится к трем действиям:

• установке пакета udev;
• запрещению монтирования devfs при старте системы;
• разбирательству с тем, что же получилось в результате.

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

Запретить монтирование devfs можно также обычным образом - передачей ядру соответствующего параметра, руками при старте системы, или в конфиге загрузчика. Для lilo требуется добавить в файл /etc/lilo.conf строку вида

append="devfs=nomount"

где-нибудь после описания образа ядра и корневого раздела. В grub параметр devfs=nomount вписывается в строку указания образа и корня:

kernel (hd0,0)/boot/vmlinuz-up \
root=/dev/hda1 devfs=nomount

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

А прелести эти я смог оценит в полной мере. Дело в том, что до этого у меня devfsd был настроен для обеспечения обратной совместимости по самому минимуму. То есть никаких /dev/hda в виде ссылок не было - ссылки создавались только для самых необходимых устройств (/dev/dsp и тому подобных, без которых не работали аудиоприложения). Так что мой каталог /dev, не считая вложенных подкаталогов типа /dev/ide, dev/discs, dev/cdroms и так далее, был почти пуст.

Теперь же в каталоге /dev можно было видеть полузабытые имена - /dev/hda, соответствующее моему винчестеру, и /dev/hda[1-4] для его разделов, а также /dev/hdc для CD-привода. Причем это были именно реальные файлы устройств, а сохранившиеся /dev/ide/host0/bus0/target0/lun0/disc и так далее - волшебным образом превратились в символические на них ссылки.

Втыкание флэшки в USB-разъем немедленно приводило к появлению в списке устройства с именем /dev/sda, не менявшимся, сколько ни повторяй эту процедуру.

Иными словами, каталог /dev приобрел вид, привычный по до-devfs'ным временам. С той только разницей, что он не был забит файлами возможных, но не существующих устройств.

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

Их оказалось не так и много. Во-первых, это был /etc/start_udev - скрипт, запускающий программу udev при старте системы.

Далее, в том же каталоге /etc обнаружился еще и специальный подкаталог - /etc/udev, где собственно и были собраны конфиги программы. Главный из них - /etc/udev/udev.conf, определяющий глобальные параметры, такие, как:

• корневой каталог для файлов устройств (по умолчанию - /dev);
• файл базы данных устройств - /dev/.udev.tdb;
• адрес файлов описания правил именования устройств и прав доступа к ним - /etc/udev/rules.d/ и /etc/udev/permissions.d/, соответственно;
• имена двух сценариев, собственно и осуществляющих именование устройств - /etc/udev/ide-devfs.sh и /etc/udev/scsi-devfs.sh, вполне прозрачного назначения;
• атрибуты принадлежности и доступа, по умолчанию присваиваемые файлам устройств при их создании.

База данных оказалась неудобопонятным бинарником, сценарии именования я проглядел любопытства ради (вряд ли стоит что-то менять в них), а вот файлы описания правил (/etc/udev/rules.d/udev.rules) и определения прав доступа (/etc/udev/permissions.d/udev.permissions)заслуживали пристального внимания.

Из рассмотрения первого файла становится ясным, каким образом создаются имена файлов устройств и символические ссылки на них (на деталях задерживаться не буду, они подробно описаны в udev (8) man). Второй же файл потребовал немедленного ручного вмешательства. Дело в том, что после перезапуска машины с задействованным udevя лишился звука - и с первого же взгляда на файл /etc/udev/permissions.d/udev.permissions стало ясно, почему. Права доступа ко всем аудио-устройствам имели примерно такой вид:

dsp*:root:root:0660

где dsp - имя устройства, root:root - хозяин и группа, соответственно, 0660 - маска, определяющая запрещение доступа для всех, кроме хозяин и группы. У меня же ранее устройства, связанные с воспроизведением аудио, относились к группе sound, в которую я и включал себя, любимого.

Так что пришлось срочно заменить второе вхождение root'а на группу sound - и после перезапуска со звуком все стало нормально.

И даже более того - побочным следствием этой процедуры стала (возникшая сама собой, и - абсолютно непонятным образом) возможность запуска моего старого RealPlayer'а (утащенного с диска OpenOffice/Mozilla производства Altlinux, 2001-й, если не ошибаюсь, год розлива - более поздние версии воспроизводят мои Real'ные остатки старых авторов кое-как, или совсем никак) из под KDE - до того он категорически отказывался это делать, апеллируя к невозможности доступа к устройству /dev/dsp.

Вот пока и все мои впечатления о udev. Как можно понять из предшествующего изложения - вполне благоприятные: с переходом на новую систему именования устройств жить на самом деле стало лучше, стало веселей. Ни с какими проблемами я вроде бы не столкнулая. Единственно, что осталось придумать, как создавать ссылку /dev/cdrom->/dev/hdc: ведь Mplayer при прокручивании кина с Video-CD или DVD почему-то жить не может без первого файла. Надеюсь со временем придумать - когда возникнет необходимость.

История с часами, или личная служба точного времени

Citkit, 6 сентября 2005 г

Эта история началась с приобретения мной ноутбука Toshiba. Я всегда испытывал недоверие к брэндовым компьютерам: стандарты брэндам не указ, и вечно идут они своим путем.

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

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

Лишь одно дело требовало хотя бы разового вхождения в BIOS - установка "хардверного" времени: мне оно требовалось по Гринвичу (т.н. UTC), а выставлено оно было по Москве, причем - в зимнем варианте. Казалось бы, мелочь - а не приятно.

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

До BIOS'а я достучаться отчаялся (и в итоге достучался лишь случайно), но зато вспомнил про программу hwclock, именно для юстировки системного времени и предназначенную.

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

Порядок обработки "хардверного" времени зависит от того, по какому времени установлены часы BIOS - по местному (как это обычно бывает для Windows-персоналок), или по Гринвичу (в кругах юниксоидов оно именуется UTC - Coordinated Universal Time, всеобщее скоординированное время, видимо, дабы англичане через чур о себе не возомнили). Точнее, важно не то, как собственно установлены часы - а то, как они (посредством соответствующих параметров к конифгах) воспринимается системой.

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

Так что первый шаг в отладке службы точного времени - это определение системного времени как UTC и установка правильного часового пояса, что делается в одном из главных конфигурационных файлов каталога /etc. Для примера, в дистрибутиве Archlinux и родственных, использующих BSD-подобный стиль загрузки, этому служат специальные переменные в файле /etc/rc.conf - HARDWARECLOCK и TIMEZONE. Первой достаточно придать значение UTC. А значения второй выбираются среди имен файлов в каталоге /usr/share/zoneinfo, например - Europe/Moscow или Asia/Kamchatka.

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

Теперь собственно приступаем к установке времени, для чего нам и потребуется утилита hwclock. Данная без опций (или с опцией --show, подразумеваемой по умолчанию), она выдаст нам показания "хардверных" часов:

$ hwclock
Wed Jul 28 18:59:10 2004  -0.800155 seconds

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

Памятуя о том, что доступа к "хардверным" часам не имеется, действуем планомерно. Для начала в меру своего разумения выставляем время часов BIOS:

$ hwclock --set --date "20/07/2004 12:45:00" --utc

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

Теперь устанавливаем системное время по выставленному "хардверному":

$ hwclock --hctosys

Теперь нам понадобится еще две вещи - пакет ntp (насколько я знаю, он входит во все "большие" дистрибутивы Linux, имеется в портах FreeBSD, а на худой конец может быть скачан с http://www.ntp.org/) и выход в Сеть. Если оба условия удовлетворены - для начала отправляемся на сайт http://www.eecis.udel.edu/~mills/ntp, где выбираем один из общедоступных серверов точного времени (по понятным причинам лучше выбирать тот, что поближе, хотя это и не обязательно). И даем команду

$ ntp http://www.fortytwo.ch/time/

Все - наши системные часы приведены в соответствие с реальность с очень высокой степенью точности (время запаздывания будет дано в выводе команды). Остается отъюстировать в соответствие с ними часы "хардверные" - ведь они ставились в определенной степени "от фонаря":

$ hwclock --hctosys

Став таким образом обладателем точных часов. Остается только время от времени корректировать их тем же образом - например, при каждом коннекте, ведь не секрет, что часы BIOS несколько уступают продукции Павла Буре или Картье.

Мастерство работы в 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-систем. Только нужно помнить: в этом случае никакого снисхождения к их неопытности от окружающего мира ждать не приходится. И законы его придется постигать сразу. Хорошо это или плохо - обсуждать, опять-таки, не будем: главное, чтобы сделанный выбор был осознанным, сопровождаясь пониманием всех возможных последствий.