OpenBSD - заметки конечного пользователя


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

Необходимое вступление
Вспышка интереса к Linux бросила свой отсвет и на остальных представителей славного семейства открытых ОС. В первую очередь - на системы линии BSD. До недавнего времени они были широко известны в узких кругах и занимали вполне определенную нишу (в первую очередь - Интернет-серверов различного масштаба). Где чувствовали себя вполне уютно. И в качестве настольной платформы использовались только отдельными энтузиастами.

Однако ведь и Linux еще пару лет назад никто всерьез не рассматривал как основу настольной системы для конечного пользователя. Ныне же - это стало вполне реальным.

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

В этом цикле проблема настольного применения ОС линии BSD рассматривается на единичном примере - OpenBSD. Возникает вопрос - почему именно она? Ответить на него не сложно. Но предварительно следует сказать несколько слов о том, что такое

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

Мне известно четыре ныне живущих представителя BSD чистой линии - BSD/OS, FreeBSD, Net BSD, OpenBSD, вымерший штамм SunOS и пара-тройка микстов (включая MacOS X, о которой столько говорят последнее время). Однако предметом для обсуждения могут быть только три - Free-, Net- и OpenBSD, как системы свободные и открытые. Прочие же должно отмести с негодованием ввиду их сугубо коммерческой природы.

Это я не к тому, что сами по себе они плохи - отнюдь. Просто цена коммерческих Unix-систем обычно столь высока, что Windows на их фоне выглядит просто как продукт благотворительности. Система же для конечного пользователя должна обеспечивать сохранность его кошелька вкупе с чистотой совести. Именно этим двум условиям и отвечают открытые и свободные системы типа Linux и *BSD. Впрочем, и этот вопрос уже обсуждался.

История открытых BSD-систем уходит в седую древность (начало 90-х годов прошлого столетия), когда на базе развивавшейся в университете Беркли версии Unix были созданы Free- и OpenBSD. От последней в 1995 г. ответвилась OpenBSD. С тех про эти системы развивались параллельно, хотя и не вполне независимо. И фамильное сходство не утрачено ими по сей день.

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

Однако каждая из систем характеризуется и только ей присущими особенностями. Так, FreeBSD оптимизирована для процессоров Intel и совместимых. NetBSD, напротив, ориентирована на поддержку максимально широкого круга аппаратных платформ. Что же касается OpenBSD, то она изначально разрабатывалась в расчете на максимальную защищенность как системы, так и пользовательских данных.

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

Во-вторых, не побоюсь высказать мысль, которая может показаться крамольной адептам какой-либо из упомянутых систем: с точки зрения пользователя, различия между BSD любого рода ничуть не больше, чем между различными дистрибутивами Linux. Более того, вариации внутри линии BSD - вполне в пределах внутривидовой изменчивости основных линий развития Linux, таких, как клоны Red Hat, Debian и Slackware, а подчас и меньше. И все они вполне правомерно могут рассматриваться в одном ряду.

Что же касается бытующего мнения о большей устойчивости FreeBSD сотоварищи по сравнению с Linux... Ни в коей мере не собираюсь оспаривать его (или, наоборот, подкреплять) по существу. Однако рискну заметить: в рамках очерченной темы это не имеет никакого значения. Поскольку устойчивость любой из этих систем более чем достаточна для настольного (не серверного - тут судить не берусь) применения. И неизмеримо превосходит устойчивость Windows 9x, если этот термин вообще применим к последней (опять же подчеркну, что о NT/2000 - речь не идет).

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

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

Особенности OpenBSD
Как уже говорилось, OpenBSD ответвилась от NetBSD в 1995 году. По причинам, насколько я смог понять, сугубо личным. Разрабатывается она ограниченным сообществом под главенством (если это слово уместно в данном контексте) основоположника проекта - Тео де Раадта, бывшего до того одним из зачинателей проекта NetBSD.

Официальный сайт проекта - http://www.openbsd.org, формальное место базирования - Канада, для преодоления законодательных ограничений США на экспорт криптографических технологий. Поскольку криптография - один из краеугольных камней построения этой системы.

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

Впрочем, ничего своеобразного, по сравнению с FreeBSD и OpenBSD, текст предыдущего абзаца не содержит. Своеобразие это начинается дальше. Во-первых, хотя OpenBSD и ориентирована в значительной мере на Intel-совместимые машины, от NetBSD она унаследовала поддержку весьма широкого спектра аппаратных платформ: Alpha, Sparc, HP300, Motorolla 68xxx, PowerPC (плюс еще несколько, о которых я и не слыхивал).

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

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

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

Почему именно OpenBSD
была выбрана в качестве предмета рассмотрения.

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

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

OpenBSD с этой точки зрения занимает промежуточное положение. Правда, Сетевых источников информации по ней крайне мало. Мне известен лишь один посвященный ей русскоязычный сайт - OpenBSD.Ru, плюс находящееся в процессе становления зеркало официального openbsd.org. Конечно, это не много. Но все же в какой-то мере освобождает от опасения, что в критический момент останешься один на один с системой.

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

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

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

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

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

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

Наконец, окончательный выбор OpenBSD был сделан при чтении подборок FAQ про FreeBSD. Одна из которых начиналась обсуждением вопроса, почему FreeBSD лучше Linux. Во-первых, как уже говорилось, саму постановку вопроса полагаю в корне неверной. Во-вторых, не могу согласиться с аргументацией. В числе коей - утверждение, что демон (daemon - символ FreeBSD) круче пингвина (на мой взгляд, крутыми бывают яйца, а пингвин - существо очень симпатичное). И в третьих, просто не приемлю никакой исключительности. И позиция разработчиков OpenBSD, отказывающихся обсуждать вопрос о превосходстве какой-либо из систем в принципе - мне ближе.

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

Приложение
Библиография вопроса
OpenBSD
Русскоязычное зеркало сайта http://www.openbsd.org, в процессе создания. Пока переведены отдельные фрагменты

OpenBSD.ru
Единственный известный мне русскоязычный сайт, специально посвященный OpenBSD

Колонцов Вадим. ОС BSD жила, живет и будет жить
Открытые системы, 1997, 03
История развития и сравнительная характеристика NetBSD, FreeBSD и OpenBSD
Версия on line

Выскубов Алексей. OpenBSD: безопасность превыше всего
Byte/Россия, 1999, 7-8 (11-12), 101-102
Общие впечатления от установки системы. Благоприятные. Описание системы портов, вопросов безопастности и т.д.

Раадт Тео де (Theo de Raadt). OpenBSD: прошлое и будущее
Byte/Россия, 2000, 01 (17), 22-23
Интервью Алексея Выскубова с Тео де Раадтом - одним из основоположников проекта OpenBSD, немного об истории последнего и перспективах.

Дэвис Ноэль (Noel Davis). OpenBSD - хороший пример
Byte/Россия, 2000, 10 (26), 68-69
Взгляд линуксоида на OpenBSD. Отражается внимание на ее сильные, по сравнению с Linux, моменты - безопасность и т.д.



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

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

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

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

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

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

Сообщения о ходе загрузки идут не в традиционных черно-белых тонах, а белым по синему. Среди них удается разобрать, что система определяет всякие устройства - в моем случае это были плата видеозахвата на чипе BT878, звуковая карта Ensoniq1371, CD-R/RW с IDE-интерфейсом, для которого предлагается эмуляция SCSI. Не говоря уже о таких тривиальных вещах, как винчестеры.

Правда, по завершении загрузки фон опять становится черным. И на нем высвечиваются варианты выбора: инсталляция (Install), обновление (Upgrade), выход в командную среду (Shell). Последняя опция заставляет предполагать (вполне обоснованно, как станет ясным из дальнейшего), что инсталляционный CD ROM может выполнять и функции спасательного в аварийных ситуациях.

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

Инсталляция проходит в текстовом режиме, при минимальной автоматизации процесса. каковой, в сущности, сводится к

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

Разметка диска
Первое, что происходит после выбора инсталляции - запуск собственного варианта fdisk.Который существенно отличается от Linux'ового (не говоря уже о FDISK из MS DOS). Обнаруживая фамильное сходство с fdisk из FreeBSD, что и не удивительно из-за близости их файловых систем (даже именуемых одинаково - ffs, Fast File System). Хотя и здесь нет полного терминологического тождества. Потому остановлюсь на этой процедуре подробнее. В меру своего, пока очень ограниченного, понимания, разумеется.

В отличие от Linux, в OpenBSD (как, впрочем, и во Free), разбиение диска осуществляется в два этапа и двумя разными программами. Сначала посредством собственно fdisk создаются физические разделы, partitions (slices в терминологии FreeBSD, они же primary partitions в понимании DOS и Linux). Коих, по известным архитектурным ограничениям, не может быть более четырех на одном винчестере.

Затем физические разделы, с помощью Disk Label Editor, делятся на разделы логические, именуемые в русском переводе OpenBSD подразделами, хотя в оригинале и используется тот же термин partitions, что идентично FreeBSD. Это способствует окончательному запудриванию мозгов, хотя момент чрезвычайно серьезный и ответственный. Поскольку подразделы OpenBSD (буду использовать этот термина, как наиболее соответствующий сути явления) объединяют в себе как понятие расширенного раздела DOS (extended partition), так и логического тома внутри него.

Действительно, и в DOS, и в Linux Extended Partition - не более чем контейнер для вложенных логических дисков (томов). В Open же BSD, как и во FreeBSD, создается впечатление, что каждый из физических разделов (назови их хоть partition, хоть slice), просто делится на логические части. Однако одна их этих частей присутствует перманентно и удалена быть не может (хотя и помечена как неиспользуемая, unused). Судя по всему, именно она-то и выполняет роль контейнера (=extended partition) для всех остальных.

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

Возвращаемся, однако, к нашим партициям. При наличии в системе более одного винчестера, OpenBSD'шный fdisk для начала предлагает определиться, который из них будет корневым. Приводя их список: в OpenBSD физические диски маркируются как wd0 (Master на первом IDE-канале), wd1 (Slave на нем же) и так далее. Излишне говорить, что я рассматриваю случай ATA-винчестеров - со SCSI все будет несколько иначе, но, за отсутствием личного опыта, вопрос этот замнем.

Затем вопрошает, хотим ли мы отвести под систему полный диск (entire disk) или нет, причем второй ответ отмечен по умолчанию. Если, однако, ответить положительно, стадия fdisk просто проскакивается. И это может показаться самым простым решением, если не стоит задача сохранить какие-либо из имеющихся разделов или создать не-ffs разделы. Хотя итогом может стать некоторые (правда, преодолимые) сложности при сосуществовании OpenBSD с Linux (вероятно, и с Windows - тоже, но за искоренением последнего я этот вопрос не изучал).

Я в конце концов так и остановился на положительном ответе на вопрос об entire disk. Но прежде вдоволь поэкспериментировал (с переменным успехом) и при отрицательном выборе.

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

Следует отметить три обстоятельства. Во-первых, id совпадает с шестнадцатиричными номерами типов файловых систем, поддерживаемых Linux (в чем позднее можно будет убедиться воочию). Во-вторых, он отличен от нумерации таковых, принятой во FreeBSD. Ну а в третьих - тип файловой системы, то есть id, - отнюдь не то же самое, что принадлежность системе операционной. Так, разделы и Free, и OpenBSD обозначаются как BSD-разделы. Однако id раздела OpenBSD - A6, тогда как раздел FreeBSD маркируется как A5 (то есть также, как в fdisk из Linux).

Ниже таблицы разделов содержится указание, что посредством ввода help можно ознакомиться с доступными командами. Чем пренебрегать ни в коем случае не следует - тем более что вместо help можно (как и для всех остальных команд) ограничиться буковкой h. Потому как команды сильно отличаются от таковых в fdisk из Linux. Главное из них: если в Linux команда quit (q) означает выход из программы без сохранения изменений, то здесь, напротив, quit - это запись изменений с переходом к следующей стадии; для выхода же без записи предназначены команды exit (переход к следующей стадии) и abort (обрыв инсталляции с выпадением в командную среду).

Так что - внимание, внимание и еще раз внимание. Выход из fdisk через quit производит впечатление, что ничего не произошло. И даже ранее существовавшие разделы как бы не изменились (в чем легко убедиться, перезагрузившись в Linux и запустив евойный fdisk). Однако получить доступ к ним не удастся. По крайней мере, обычными подручными методами.

Так вот, на команду help нам выдается ряд вариантов. Во-первых, manual - вызов подробного руководства по fdisk (то есть соответствующего man'а). Во-вторых, reinit - реинициализация диска, чем-то напомнившая мне команду DOS FDISK /mbr; реально ее результат в том, что все разделы обнуляются, кроме одного, который распространяется на весь диск и приписывается системе BSD; впрочем, это еще следует подтвердить записью (write).

Далее следует команда disk - это переопределение геометрии диска, чего при LBA-режиме лучше, думается, не делать.

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

При этом на ввод ? (вопросительного знака) выдается список доступных id; для тех позиций, которые я помню на память, он полностью совпадает со списком, выдаваемым Linux'овым fdisk на команду l: 04 - FAT16 <32M, 5 - Extended Partition DOS, 0b - FAT32, 82 - Linux Swap, 83 - Linux native, a5 - FreeBSD, a6 - OpenBSD.

Определив тип файловой системы, можно указать его размер, задав начальный (offset) и конечный (size) сектора; можно, ответив положительно на предварительный вопрос, оперировать и в терминах CHS (цилиндр/головка/сектор), более привычных для Linux. Однако указать размер в человеческих единицах (Мбайт, Гбайт) на этой стадии не удается.

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

Завершить которые можно записью (write), переходом к следующему этапу без записи своих манипуляций (exit), таковым же, но с предварительной записью (quit), или прекращение инсталляции без всяких изменений (abort). Последнее действие доступно и с помощью комбинации Control+C.

Если же мы посредством quit перейдем к следующему этапу (или просто отведем под OpenBSD весь диск), то окажемся в Disk Label Editor, каковой для начала предложит нам свою помощь через ввод вопросительного знака. Из нее мы тут же узнаем о возможности получить список имеющихся подразделов файловой системы (то есть логических разделов) командой print.

В самом простом случае, если был создан всего один физический раздел (или просто под OpenBSD отведен весь диск, посредством выбора entire disk на предыдущей стадии), подразделов у него окажется два: a, занимающий все доступное пространство, и некий мифический подраздел c (помеченный как неиспользуемый, unused). Который, как уже говорилось, уничтожен быть не может: он выполняет функцию extended partition в DOS (и Linux).

В списке же доступных действий далее следуют: a - добавление подраздела, c - изменение размера существующего, b - переопределение отведенного для OpenBSD дискового пространства, r - пересчет свободного пространства, n - определение точки монтирования подраздела, u - отмена последней операции, w - запись произведенных изменений, q - выход с предварительной записью, x - выход без записи изменений.

Очевидно, что не все это доступно сразу. Так, при выборе entire disk невозможно добавить подраздел, потому что весь диск занят единственным физическим разделом, включающим один же существующий подраздел - a. Наряду с которым присутствует и подраздел с, однако он не может быть использован - как я уже говорил, это своего рода аналог Extended Partition из DOS или Linux

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

Если после этого избрать добавление подраздела, то таковой под литерой a будет создан заново, ему будет приписана принадлежность к OpenBSD, а размер можно задать по своему усмотрению, в том числе в мегабайтах (###m, ###M) или гигабайтах (###g,###G) - здесь это будет воспринято нормально. Точку монтирования подраздела логично определить как /.

Второй добавленный подраздел автоматически маркируется буквой b и по умолчанию обретает статус раздела для своппинга (Swap). Рекомендуемый его размер - вдвое больше оперативной памяти. Как и FreeBSD, OpenBSD использует раздел подкачки иначе, чем Linux, скидывая туда содержимое ОЗУ не при его переполнении, а при первой же возможности. И потому большой объем swap-раздела никак не помешает.

Если есть место и желание - рекомендуется дополнительно создать подразделы /usr, /var, /usr/X11R6 (автоматом им присваиваются литеры d, e и т.д., литера c пропускается). Вообще, в руководстве для платформы Intel предложена следующая схема:

/ 35 Мбайт
/usr 229 Мбайт
/var 24 Мбайт
/usr/X11R6 72 Мбайт

Мне такая схема видится весьма спорной. Во-первых, очевидно, что отдельный подраздел /var на настольной машине не нужен. Во-вторых, /usr и /usr/X11R6 - все равно части единой файловой системы (что упомянуто и в руководстве). И к тому же логичнее тогда создать подраздел /usr/local, куда по умолчанию попадают дополнительные пакеты и продукты компиляции непортированных исходников. В третьих, на мой взгляд, создание подраздела /home - если и не обязательно, то крайне желательно: все же некоторая дополнительная гарантия целостности пользовательских данных.

Цифры же - сугубо условны. Правда, сказано, что их лучше бы утроить. Я попробовал последовать этому совету, создав (на диске 15 Гбайт) подраздел / в 100 Мбайт, /usr - в 1 Гбайт, swap 512 Мбайт (при RAM 256 Мбайт), отведя остальное пространство под /usr/local и /home. И в результате при установке пакетов получил сообщение о нехватке дискового пространства, естественным образом оборвавшее инсталляцию...

После чего, не пудря мозги. создал 3-гигабайтный корневой подраздел (/, заведомо с избытком, даже самый пухлый дистрибутив Linux на столько не потянет), 512-мегабайтный Swap, оставив остальное под /home. И все прошло нормально. Впрочем, были опробованы и иные варианты... Так что единого рецепта предложить не рискну.

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

Завершив дискодробительные действия, следует записать их результаты (w) или выйти из Disk Label Editor с записью (q). У нас запросят подтверждения на запись (с сообщением о создании устройств - в моем случае wd0a, wd0b, wd0e) и на определение точек монтирования созданных подразделов в файловой системе в форме [/point, RET, none, or done].

Набрав RET, точки монтирования можно изменить. Если это не нужно, следует набрать done. Здесь, если винчестеров больше одного, последует предложение подвергнуть тому же мучительству другой диск. А после естественного отказа спросят: действительно ли мы готовы к процессу?

Хотя на самом деле спрашивать больше не о чем: все, что могло случится, уже случилось. Хотя полной ясности, когда и куда записываются действия разметки диска, у меня не осталось. Впечатление такое, что в значительной мере они остаются там же, гле и русские слова у японца - в ... оперативной памяти, так сказать. Однако там-то они безусловно присутствуют: если теперь выйти из программы инсталляции с помощью Control+C, при следующем ее запуске (даже после перезагрузки) следы всех ранее выполненных действий можно видеть воочию. Хотя, повторяю, с точки зрения некоего стороннего fdisk ранее существовавшие разделы сохранились в неприкосновенности...

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

Выбор компонентов
Однако перед этим в темпе румбы происходит довольно много событий. В считанные минуты создаются файловые системы (то есть происходит собственно разбиение и форматирование), выдается сообщение о их объеме, предлагается сконфигурировать сеть (от чего я по понятным причинам отказался), ввести пароль для root'а, спрашивается, предполагается ли использование системы X Window.
Наконец, предлагается определить источник инсталляции (ftp, http, стримерная лента, CD ROM или локальный диск. А по выборе CD (именно этот случай я и рассматриваю) - указать относительную точку монтирования каталога с файлами для установки (по умолчанию - /2.8/i386, на CD такой и в самом деле есть). А затем - выбор компонентов, количество которых просто смешно:

base28.tgz
etc28.tgz
misc28.tgz
comp28.tgz
man28.tgz
xbase28.tgz
xshare28.tgz
xfont28.tgz
xserv28.tgz
bsd.tgz
Причем по умолчанию отмечены только два первых, последний и man. Можно, набрав done, с этим согласиться, можно отметить все (all), можно отмечать необходимые по одному:

list имя_файла

Компоненты, включенные ошибочно, можно изъять, набрав

list -имя_файла

Затем все же набирается done, отвергается предложение повторить выбор - и происходит установка.

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

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

Вот почти и все. Инсталляционная стадия закончилась, наступает

Пост-инсталляционное конфигурирование
Впрочем, этап этот - еще более скомкан, чем установочный. И, в сущности, сводится к выбору часового пояса. В наших условиях это (если, конечно, не остановиться на GMT), происходит в последовательности: Europe/, потом Moscow, в обоих случаях команда list дает список доступных вариантов.

А затем - предложение ввести команду halt и, по останову системы, any key для перезагрузки. Шустро извлекаем инсталляционный CD (об этом нас предупредить забыли) - и ждем, что же выйдет в итоге. Что вышло у меня - расскажу в следующий раз.

А пока вкратце подведу предварительные итоги. Можно заметить из всего разговора, что система инсталляции устроена, с одной стороны, просто и логично. И к тому же предполагает простой возврат к предыдущей стадии в случае ошибки - с помощью комбинации Control+C и перезапуска программы install.

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

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

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

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




Первые впечатления, первые настройки
И так, установка системы позади. Настало время знакомства с ней. Каковое и начинается перезагрузкой. В первый раз она у меня проходит не без приключений, но об этом я расскажу в заметке о сосуществовании Linux и OpenBSD. Пока же замечу, что система эта вполне способна грузиться самыми различными способами - через такие загрузчики, как lilo или, скажем, grub (правда, не во всех случаях). А также - и просто со второго жесткого диска, если в BIOS Setup есть соответствующая опция. Что и имело место быть в моем случае.

Загрузка происходит точно так же, как и перед инсталляцией. Мелькают сообщения об обнаружении всяческого железа (причем, как неожиданно выяснилось, кое-что из него настраивается само собой - прямо Plug'n'Play какой-то), дисках и прочем. И, наконец, появляется серия не очень понятных сообщений и предложение выбрать тип терминала, по умолчанию - pcvt; поскольку не знаю, есть ли у меня на самом деле выбор (да и потому, что это - стандартная для OpenBSD система управления консолью), соглашаюсь. За что в награду получаю приглашение в виде решетки - авторизоваться. Что и проделываю - для первого раза назвавшись root'ом.

Я уже говорил, что инсталляция системы происходила фантастически быстро. И теперь становится понятно, почему: практически никаких привычных приложений в базовом комплекте нет. После авторизации я оказываюсь один на один с системой, в окружении командной среды csh (которую практически не знаю), вооруженный лишь редактором vi (к коему так и не смог привыкнуть). Ни тебе Midnight Commander, ни человечьего редактора.

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

До знакомства с BSD-системами я как-то не осознавал того факта, что такие привычные действия, как пролистывание экрана или переключение на виртуальные консоли - не неотъемлемое свойство системы как таковой, а зависят от типа терминала. Здесь, в OpenBSD, как уже было сказано, он опять-таки свой - pcvt. И начать следует с изучения его особенностей.

Помнится, во FreeBSD я немало времени потратил на поиски способа пролистывать экраны (оказалось, что это делается при включенном ScrollLock). Здесь, правда, экран прокручивается привычным по Linux способом - с помощью комбинации Shift+PageUp/PageDown. Но зато попытка переключиться на другую виртуальную консоль клавишами Alt+F# ни к какому результату не приводит.

Методом научного тыка, однако, можно определить, что для этой цели служит комбинация Alt+Control+F#, как в X Window. С одной стороны, логично - и в графическом, и в текстовом режиме переключатель консолей одинаков. Но, с другой стороны, использовать такую комбинацию одной рукой (если это не лапа неандертальца) несколько затруднительно. А ведь вторая рука задействована под мышь (для выделения и вставки текстовых блоков, скажем). Впрочем, переживать по этому поводу пока не приходится: мыши в текстовом режиме также нет.

Зато есть второй способ переключения между консолями, правда, только двумя: клавишами Shift+F1/F2. При этом задействуются 5-я и 6-я виртуальные консоли (dev/ttyC4 и dev/ttyC4, соответственно), Почему именно этими - становится ясно после установки X Window: под нее по умолчанию зарезервировано dev/ttyC4, и комбинацией Shift+F1 легко перейти в графическую консоль. Впрочем, из нее на консоли текстовые можно перейти только обычным образом - с помощью Alt+Control+F#, в ответ на нажатие Shift+F2 в X Window не происходит ничего.

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

Я не имею ничего против среды csh. Готов даже признать, что синтаксис ее более компактен и логичен, чем в bash. Однако последняя - удобней в использовании - одно автодополнение команд и путей клавишей табуляции дорогого стоит. Да и привычней она, в конце концов. Кроме того, желательно иметь какой-никакой редактор, помимо vi.

Благо, установка пакетов в OpenBSD осуществляется очень просто, о чем я расскажу в следующем разделе. Проделываю эту процедуру для bash и редактора joe. Как и во FreeBSD, команда pkg_add по умолчанию устанавливает пакеты в каталог /usr/local/.

Затем в дополнение к имеющимся в файле /etc/shells строкам

/bin/sh
/bin/csh
/bin/ksh

вписывается

/usr/local/bin/bash

Чтобы сменить командную среду, можно воспользоваться командой, например, chpass. Она вызывает системный редактор (по умолчанию - все тот же vi) и позволяет в нем напрямую редактировать учетные записи пользователей. Заменяем для root'а

/bin/csh

на

/usr/local/bin/bash

Теперь остается только соответствующим образом поправить файл .profile в корневом каталоге или в каталоге /root/.profile (первый являет собой символическую ссылку на второй. У меня он выглядит примерно так:

EDITOR=joe
export EDITOR
PS1='w->>'
alias 'ls=ls -aF'
export LESSCHARSET=latin1

Как нетрудно догадаться, строка EDITOR определяет системный редактор, строка PS1 - вид приглашения командной строки

~/articles/sterra->>

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

Если после этого завершить сеанс (командами logout или exit) и авторизоваться заново, то оказываешься в привычном окружении. Разумеется, все эти действия были доступны от лица суперпользователя. Теперь же самое время создать пользователя обычного. Помимо того, что практически работать в качестве root'а - занятие не очень здоровое с точки зрения безопасности, в OpenBSD это еще и не удобно. На консоль суперпользователя выводится большое количество сообщений. Они представляют интерес для администратора системы, но в практической работе только мешают. Конечно, от них можно избавиться (например, перенаправив сообщения в файл). Но лучше все-таки не входить в систему как root без большой на то необходимости. А прибегать для системных манипуляций к временному получению полномочий администратора (с помощью команды su).

Создание обычного пользователя выполняется командой adduser (хотя есть и другие способы). Запущенная от имени root'а первый раз (а от имени обычного пользователя ее нельзя запустить, и не только потому, что таковых в системе еще не имеется), она для начала запросит подтверждения некоторых общих пользовательских установок по умолчанию, таких, как местоположение домашних каталогов (/home) или командной среды (на выбор - любой из перечисленных в файле /etc/shells).

Ответы на эти вопросы будут сохранены в файле /etc/adduser.conf, и при следующем запуске команды повторяться они не будут. Хотя, естественно, общие пользовательские параметры могут быть изменены прямым редактирование указанного файла.

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

Вслед за этим определяется командная среда для пользователя, его цифровой идентификатор (UID - user identification descriptor) и имя группы, включающей этого пользователя (по умолчанию - совпадает с пользовательским именем).

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

Дело в том, что в OpenBSD (как, впрочем, и во FreeBSD) далеко не каждый пользователь может получить права администратора (каковым наша же скромная персона и является в случае обычной пользовательской машины) с помощью команды su. Для этого пользователь должен быть явным образом включен в группу wheel, имеющую идентификатор (GID - group identification descriptor) 0. Так что в ответ на указанный вопрос следует вписать wheel.

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

Name: exp
Password: ****
Fullname: al
Uid: 1002
Gid: 1002 (exp)
Groups: exp wheel
HOME: /home/exp
Shell: /usr/local/bin/bash

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

Теперь можно авторизоваться в качестве обычного пользователя и настроить для него рабочую среду. Что делается редактированием файла ~/.profile, если для него была выбрана среда bash, или файла ~/.cshrc при использовании среды csh.

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

Рассмотрение его показывает, что по умолчанию в нем запрещено практически все, что может быть - одно из следствий ориентации OpenBSD на защищенность. Конечно, большинство перечисленных здесь демонов управляет ко всякого рода сетевым причиндалам. И меня пока не волнует. Кроме одного, поскольку без мыши жить скучно. Для обретения же ее в rc.conf следует найти строку

moused_flags="NO"

и заменить значение по умолчанию на рекомендуемое для мышей с разъемом PS/2

moused_flags="-p /dev/psm0"

или на moused_flags="-p /dev/cua00"

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

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

Для конфигурирования X Window (в версии 3.3.6) предусмотрено единственное средство - XF86Setup (если, конечно, нет большого желания создавать файл /etc/XF86 Config вручную в текстовом редакторе). Каковой и запускаем, воспользовавшись полномочиями root'а.

Если вдруг XF86Setup откажется запускаться (а такая возможность по причинам, оставшимся для меня неясными, не исключена), следует обратиться к файлу /etc/ttys, описывающему конфигурацию вертуальных консолей. Нормальный вид его начальной части - нечто вроде следующего: # # $OpenBSD: ttys,v 1.13 1998/06/28 00:48:37 art Exp $ # # name getty type status comments # console "/usr/libexec/getty Pc" vt220 off secure ttyC0 "/usr/libexec/getty Pc" vt220 on secure ttyC1 "/usr/libexec/getty Pc" vt220 on secure ttyC2 "/usr/libexec/getty Pc" vt220 on secure ttyC3 "/usr/libexec/getty Pc" vt220 on secure ttyC4 "/usr/libexec/getty Pc" vt220 off secure ttyC5 "/usr/libexec/getty Pc" vt220 on secure ttyC6 "/usr/libexec/getty Pc" vt220 off secure ttyC7 "/usr/libexec/getty Pc" vt220 off secure

Это показывает, что по умолчанию открыто восемь виртуальных консолей, то есть на каждой из них запущен процесс инициализации getty. В то же время активизировано только пять: консоли 5-я, 7-я и 8-я не задействованы для текстового режима и доступны для запуска режима графического, в котором функционирует программа XF86Setup.

Если же та отказалась запуститься - скорее всего, в файле /etc/ttys активизированы все открытые консоли. Что легко исправить, заменив on на off минимум в одной из строк (по умолчанию для графического режима задействована 5-я консоль, переключение на которую осуществляется клавишной комбинацией Shift+F1). Буде же возникнет желание запускать два или более сеансов X Window (иногда это полезно), следует озаботиться достаточным количеством свободных виртуальных консолей. Впрочем, конфигурация по умолчанию (как в приведенном выше фрагменте) мне представляется разумной.

Теперь, наконец, можно и заняться конфигурированием X Window. Проходит она без приключений. В моем случае она свелась к установке трехкнопочной мыши (устройство /dev/psm0, стандартное для Linux устройство /dev/mouse здесь не проходит), русскую 105-клавишную клавиатуру, видеокарту Riva TNT2 (у меня она, правда, в модификации M64, отсутствующей в списке, но по опыту - почти всегда работает, будучи названной TNT2 просто). Мой AcerView 76i я в таких случаях обзываю SVGA 1280x1024x60 Hz - в этом случае он при 1152x864 тянет 72 герца. Каковое разрешение при 32-битном цвете и устанавливаю - карты на всех чипах NVIDIA, насколько я знаю, 24-битного цвета не поддерживают, а при 16-битном мои любимые background'ы смотрятся хуже.

Теперь командой xinit можно запустить X Window просто (с единственным терминальным окном). А можно командой startx запустить и FVWM - единственный из оконных менеджеров, установленных по умолчанию. И на этом временно успокоиться. Перейдя к следующему вопросу - изучению доступных приложений. Ведь система для конечного пользователя ради приложений и устанавливается, не так ли?




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

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

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

Сама по себе коллекция портов - это архив ports.tar.gz, находящийся на дистрибутивном CD в каталоге ~/2.8 (для текущей версии). Архив этот должен быть переписан на диск (иначе он отказывается распаковываться) и распакован соответствующей командой, например

tar -xzf ports,tar,gz

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

CVS cad emulators mbone security
INDEX chinese games misc shells
Makefile comms graphics net sysutils
README converters infrastructure news textproc
archivers databases japanese plan9 www
astro devel lang print x11
audio distfiles mail productivity
benchmarks editors math russian

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

make install

Все дальнейшее - заботы системы. Она определит наличие архивов с исходными текстами в /usr/ports/distfiles. Если их там нет (а можно и заранее положить), то она попробует скачать их, причем на каждый port имеется солидный список мест, где можно взять исходники. На худой конец они обязательно есть на ftp://ftp.freebsd.org/pub/FreeBSD/distfiles (или на ftp://ftp2.ru.freebsd.org/pub/FreeBSD/distfiles). Попутно будут скачаны нужные патчи и все остальное необходимое для сборки.

Затем обязательно будут проверены MD5-суммы для скачаных файлов, что позволит избежать всякого рода ошибок при передаче. Затем автоматически будет выполнена распаковка архивов, на них будут наложены все нужные патчи, вызваны все требуемые скрипты конфигурации, команда make для сборки и все прочее, что потребуется. Далее = собственно инсталяция, приложение будет зарегистрировано как обычный пакет.

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

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

Приведенное описание способно вызвать приступ черной зависти у пользователя Linux. Однако реализовать такую систему при отсутствии постоянного подключения к Сети несколько затруднительно.

Конечно, исходники можно заблаговременно скачать (по указанным в ports адресам) и разместить в каталоге /usr/ports/distfiles, Однако, согласитесь, что это уже не совсем то: при неудовлетворенных зависимостях (а это может обнаружиться только в ходе установки) потребуется скачивать и дополнительные пакеты. Если же локализация машины и выхода в Сеть разнесены в пространстве (как это имеет место быть у меня), идея вообще почти теряет смысл.

Однако отчаиваться не стоит - есть выход в виде коллекции пакетов. Понятие пакета совпадает практически с принятым в Linux, особенно в таких дистрибутивах, как Slackware. Это - откомпилированные бинарные программы, собранные в виде компрессированных архивов tgz. Содержащих, кроме собственно файлов программ, также сценарии для их правильной (в соответствии со структурой каталогов OpenBSD) установки.

На инсталляционном диске пакеты расположены в каталоге /2.8/packages/i386. Правда, свалены они здесь в одну кучу, без всякой систематизации. И никак не аннотированы. Однако некую информацию о пакетах получить можно.

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

Тем не менее, работает система пакетов весьма эффективно. Выбрав требуемый, его можно установить командой

pkg_add имя_пакета

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

Так, выбор для установки пакета Lyx приводит к тому, что вместе с ним устанавливается TeX (надстройкой на которым тот является) и все к нему относящееся. При инсталляции KDE тут же, без отдельного приглашения, устанавливается библиотека Qt и прочие требуемые компоненты. Параллельно с GIMP'ом и Bluefish установились все потребные библиотеки Gtk. И все - без единого вопроса, как само собой разумеющееся.

По умолчанию пакеты из коллекции устанавливаются в подкаталоги каталога /usr/local (/usr/local/bin, usr/local/lib и т.д.). Что, соответственно, требует прав администратора. Однако пути инсталляции можно и изменить. Для этого команда pkg_add должна быть запущена с опцией -p (prefix - путь для инсталляции пакета). Правда, работоспособность программы после этого, насколько я понял, не гарантируется...

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

К слову сказать - единственный прокол в работе pkg_add я обнаружил именно при установке KDE 2. Хотя выбор для инсталляции kdebase и влечет за собой неизбежно не только kdesupport, kdelibs, а также библиотеки Qt2. И kde после этого исправно функционирует. Но только - до первой перезагрузки системы. При повторном же запуске KDE грузиться отказывается, жалуясь на отстутствие нескольких библиотек. Хотя командой find таковые легко отыскиваются.

Правда, разбираться я с этим не стал - все равно порт KDE2 под OpenBSD нельзя назвать вполне полноценным. Подожду более полной версии - надеюсь, уже 2.1.

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

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




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

Среди консольных программ - традиционная подборка текстовых редакторов: упоминавшийся ранее joe, jed, pico, emacs, elvis - можно выбрать по вкусу и потребностям. Правда, le, знакомого по FreeBSD, нет. Отсутствует и mcedit - встроенный редактор из Midnight Commander. Впрочем, и самого этого файлового менеджера нет также, на горе любителей детей командира Нортона.

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

Действительно, сколько нажатий на клавиши нужно, чтобы в Norton-подобном файловом менеджере перейти из глубоко вложенного подкаталога каталога /home в столь же глубоко закопанный подкаталог каталога /usr, для примера предлагаю произвести этот подсчет читателю. А в командной строке для этого достаточно набрать

cd /usr/subdir1/../subdirN

- и дело в шляпе. Причем, если дело происходит в bash, набирать путь целиком нет необходимости - к нашим услугам волшебная клавиша табуляции. Экономия усилий и времени - налицо. А поскольку частое долбление по клавишам способствует всякого рода туннельным синдромам кисти - сократить его до минимума никак не вредно...

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

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

Помимо классического FVWM, устанавливаемого с X Window по умолчанию, имеется его Win-подобный вариант FVWM95, многочисленные вариации на тему TWM, аскетичный Blackbox, сюрреалистичный Enlightenment, наследники NextStep - AfterStep и WindowMaker, предельно быстрый и компактный FLWM, замечательный также простотой настроек. Есть и еще несколько, доселе мне неизвестных.

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

Зато KDE имеется сразу в двух версиях - 1-й и 2-й. Первая - полностью функциональна и ничем не отличается от своих Linux-аналогов. Правда, KDE2 представлена только в базовом наборе, с konqueror и абсолютным минимумом приложений. Да и работает чере пень-колоду...

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

А можно отредактировать вручную файл /usr/X11R6/lib/X11/xinit/xinitrc, описывающий конфигурацию при запуске сценария startx. Последние строки в нем по умолчанию имеют вид

xclock -geometry 50x50-1+1 &;
xconsole &;
xterm -geometry 80x24 &;
exec fvwm || exec xterm

то есть предписывают загрузку FVWM при старте X Window. Достаточно, закомментировав или стерев все, имеющее к нему отношение, вписать, например,

exec flwm

или

exec wmaker

- и по умолчанию в графическом режиме будет грузиться FLWM или, соответственно, WindowMaker.

Перейдем теперь к приложениям графического режима. В их числе обнаруживаются: NEdit из текстовых редакторов, Bluefish и Amaya из web-редакторов, GIMP и TGif из редакторов графических, xv для просмотра графических файлов. В качестве текстового процессора выступает Lyx. Все эти приложения устанавливаются без всяких затруднений - pkg_add работает безотказно.

Неожиданным для меня оказалось некоторое (не очень большое, но достаточное) количество мультимедийных приложений - пара CD- и MPEG-плейеров, например, удобный консольный проигрыватель mpg123. Который хорош простотой использования. Запустить его можно, например, таким образом:

mpg123 $HOME/music/lanzberg

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

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

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

Пока речь шла о том, что в OpenBSD есть. Пришла пора сказать и о том, чего в нем нет. А нет практически ни одного нормального файлового менеджера. Про отсутствие сына любимого народом командира Нортона - Midnight Commander, - я уже упоминал. Но и для X Window бросается в глаза лишь убогий xfm.

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

Вызывает удивление отсутствие в коллекции пакетов Netscape в любом виде и любой версии. Правда, в коллекции портов он присутствует. Однако в итоге, если нет возможности портами воспользоваться, при потребности в браузере придется применять konqueror или kfm. Если же нет желания (возможности) ставить KDE, остается только ограничиться текстовым lynx или его функциональным аналогом - links.

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

Короче говоря, для своих потребностей я обнаружил все критически важные приложения - NEdit для сочинения текстов, Lyx для их оформления, GIMP для работы с растровой графикой. В качестве браузера я использую lynx, что имеет свой плюс - ведь это самый строгий цензор соответствия спецификации языка HTML. Не допускающий, в отличие Netscape или, тем более, MS Explorer, никакого либерализма.

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

Конечно, TGif - лишь бледное подобие настоящего векторного редактора. Однако и под Linux с ними не густо. Единственный инструмент такого рода, достойный звания векторного редактора - это рисовальный модуль из офисного комплекта StarOffice, каковой я пока не потерял надежду запустить и под OpenBSD.

Для правки конфигурационных файлов в текстовом режиме я приспособил joe. В консоли PCVT он работает прекрасно. И не обнаруживает никаких аномалий в поведении клавиш, которые встречаются в некоторых Linux-консолях.

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

Подчеркну в заключение, что для всего этого мне не понадобилось ни лезть в Сеть, ни прибегать к системе портов (да и возможности такой не было), ни перекомпилировать ядро. Все требуемое обнаружилось в штатной поставке на инсталляционном CD. Что вдвойне удивительно: мало того, что дистрибутив OpenBSD включает всего один диск, так и тот заполнен чуть больше чем на половину. Поневоле задаешься вопросом: чем умудряются набить 2-4 диска составители Linux-дистрибутивов монстроидального плана?




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

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

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

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

Поэтому я принялся размышлять и читать документацию. Все файлы. имеющие отношение к терминалу pcvt (а русификация - лишь один из способов изменения свойств терминала, и для ее выполнения в свойствах этих следовало хоть как-то разобраться) находились в каталоге /usr/share/misc. А программы управления им - в каталоге /usr/sbin. Вносить же изменения, по-видимому, следовало в конфигурационный файл /etc/rc.local, это самое подходящее место.

Решил для начала добиться вывода кириллицы на экран. Кириллические шрифты для консольного режима имелись - в каталоге /usr/share/misc/pcvtfonts. Шрифтов четыре для разных разрешений (то есть количества строк и знаков на экране), и только в кодировке KOI8: koi8-8x16, koi8-8x14, koi8-8x10, koi8-8x8. Никаких указаний на возможность использования шрифтов в альтернативной кодировке я не обнаружил. Впрочем, забегая вперед, замечу, что даже в сочетании с мышью в консольном режиме экранные шрифты KOI8 никаких проблем (имеющих место быть во FreeBSD с ее syscons) не создают.

Разумеется, имеющиеся шрифты следует неким образом считать. В каталоге /usr/sbin обнаруживается программа loadfont, судя по названию, именно для этой цели и предназначенная. Ну и, как я уже говорил, файл rc.local также божьим предначертанием создан для помещения соответствующих директив.

После некторых ползуче-эмпирических упражнений и прочитывания соответствующей man-страницы, прихожу к следующим строкам в rc.local:

#cyrillic fonts added
/usr/sbin/loadfont -c0 -f/usr/share/misc/pcvtfonts/koi8-8x16
/usr/sbin/loadfont -c1 -f/usr/share/misc/pcvtfonts/koi8-8x14
/usr/sbin/loadfont -c2 -f/usr/share/misc/pcvtfonts/koi8-8x8

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

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

С вводом кириллицы с клавиатуры дело оказалось похуже. Хотя возможность такая в некотором смысле есть. Она реализуется посредством команды /usr/sbin/kcon, управляющей вообще поведением клавиатуры в pcvt. К слову замечу, что парная ей команды scon отвечает за вывод на экран, позволяя, в частности, переключаться между виртуальными консолями, получать сведения о текущей и т.д.). Так вот, команда вида

kcon -m koi8

запущенная вручную или вписанная в тот же файл rc.local, позволяет вводить с клавиатуры русские буквы. Если, конечно, это можно назвать вводом: кириллические символы получаются нажатием литерной клавиши одновременно с Alt. При этом правый Alt обеспечивает ввод в раскладке "йцукен" (в нижнем регистре), левый - в раскладке "ЯВЕРТЫ" (в верхнем). Одновременное нажатие еще и клавиши Shift дает верхний регистр букв в первом случае и нижний - во втором. Знаки препинания во всех случаях вводятся в латинской раскладке.

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

В отличие от программ управления консолью в Linux и FreeBSD, в pcvt не обнаруживается отдельных файлов для разных клавиатурных раскладок (то есть разных keymap). Все они свалены в едином файле /usr/share/misc/keycap.pcvt. Во второй половине которого, после раскладок бельгийских, исландских, шведских и прочих, столь же широко применяемых в узких кругах граждан этих многолюдных стран, можно обнаружить и раскладку под названием

# Simple Cyrillic KOI8-R keymap

созданную, как гласит комментарий, Романом Палагиным (Roman V. Palagin). Вид ее следующий:

koi8:koi8-r:ru-koi8:ru:dummy cyrillic keymap:
:l1#62:
:A17=312:A18=303:A19=325:A20=313:A21=305:A22=316:
:A23=307:A24=333:A25=335:A26=332:A27=310:A28=337:
:A31=306:A32=331:A33=327:A34=301:A35=320:A36=322:
:A37=317:A38=314:A39=304:A40=326:A41=334:
:A45=302:A46=321:A47=336:A48=323:A49=315:A50=311:
:A51=324:A52=330:A53=302:A54=300:A55=243:

То есть ввод кириллических символов обеспечивается подменой комбинации Alt+код_латинской_буквы кодом соответствующей ей буквы русской. Ничего лучшего, насколько я смог выяснить, пока никем не придумано. Тем не менее, это лучше, чем ничего - кириллические тексты в консольном режиме можно хотя бы просматривать и, при крайней нужде, поправить в них пару-тройку ошибок - на большее мало у кого хватит терпения.

Завершающий штрих русификации - установка системной локали. Каковая отсутствует в системе как класс - каталог /usr/share/locale просто пуст. Это можно восполнить, скачав какую-либо из существующих (соответствующие ссылки обнаруживаются, например, на http://www.opennet.ru). А затем внести соответствующие изменения в переменные среды. Теоретически это делается двояким способом.

Первый, традиционный, - внесение соответствующих изменений в профильные файлы командной среды пользователя - $HOME/.profile при использовании bash или $HOME/.login - при работе с csh.

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

LANG=ru_RU.KOI8-R; export LANG
MM_CHARSET=KOI8-R; export MM_CHARSET

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

Чтобы добиться того же эффекта для среды csh, в файл $HOME/.login следует вписать строки

seteven LANG=ru_RU.KOI8-R
seteven MM_CHARSET=KOI8-R

поскольку необходимости в экспорте здесь нет.

Второй способ - определение переменных окружения в учетной записи пользователя. Теоретически рассуждая, именно (и в том числе) для этого в ней предназначено поле class. Во FreeBSD в описании классов (в файле /etc/login.conf), как говорят, имеется и класс russian. Каковой отличается от класса default только установкой нужных переменных среды при входе в систему. Этот способ позволяет назначить разным пользователям свои локали, не вмешиваясь в их профильные файлы.

Однако в OpenBSD (в том варианте, что установился у меня) в файле /etc/login.conf ничего подобного классу russian не обнаруживается. Вероятно, с этим можно справиться, но я заниматься этим не стал. Да и вообще отказался от установки русской локали. Что, конечно, идеологически неправильно, но нам-то, советским людям, любая идеология - пофигу. А вот практически...

Практически оказалось, что при установке русской локали в любом ее проявлении проблемы возникают, как ни странно, в X Window. А именно, в оконных средах, собранных на библиотеке Gtk (например, XFce), и во всех Gtk-приложениях. Впрочем, к этому я вернусь в далее в этой же заметке. А пока с русификацией консоли мне хотелось бы покончить.

Русификация X Window
Как ни странно, здесь оказалась своя специфика, хотя в целом положение с русификацией существенно лучше. Но - по порядку.

Вывод русских букв на экран в X Window обеспечивается без труда. В штатный комплект входят русские шрифты имени товарища Cronyx'а, каковые обнаруживаются в каталоге /usr/X11R6/lib/X11/fonts/cyrillic - единой кучей, без разбивки на обычные 100dpi, 75dpi и misc.

Впрочем, на инсталляционном CD, в каталоге ~/2.8/packages/i386 имеется и пакет xcyrillic. После его установки дополнительные кириллические шрифты наблюдаются в каталогах /usr/local/lib/X11/fonts/xcyrillic/100dpi, /usr/local/lib/X11/fonts/xcyrillic/75dpi и /usr/local/lib/X11/fonts/xcyrillic/misc. Прописав соответствующие пути в секции Files файла /etc/XF86Config, можно наслаждаться видом русских букв в X'ах. Причем прописать их нужно обязательно все - среди шрифтов с разрешением 100dpi почему-то отсутствует гарнитура fixed.

С клавиатурой оказывается немного сложнее. Как я уже говорил, X Window приходится настраивать после инсталляции системы. Если для этих целей воспользоваться программой XF86Setup, можно выбрать не только русскую раскладку клавиатуры, но и переключатель с латиницы на кириллицу, например, комбинацию Control+Shift.

К слову сказать, в X'ах следует избегать переключателей с комбинацией клавиш Control+Alt: они блокируют такие часто необходимые действия, как переход на другую виртуальную консоль (Control+Alt+F#) или принудительный выход из графического режима (Control+Alt+Backspace), что иногда создает просто почти безвыходные ситуации.

В результате в файле /etc/XF86Config в секции Keyboard можно созерцать примерно такие строки:

Protocol "Standard"
XkbRules "xfree86"
XkbModel "pc105"
XkbLayout "ru"
XkbOptions "grp:ctrl_shift_toggle"

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

Разумеется, и переключатель Control+Shift не является обязательным. Я тут же заменил последнюю строку на

XkbOptions "grp:caps_toggle"

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

Для начала после запуска X Window никакой из доступных (то есть указанных в секции option файла /usr/X11R6/lib/X11/xkb/rules/xfree86.lst переключателей ничего не переключал: либо ввод с клавиатуры просто блокировался, либо латинские буквы как вводились, так и продолжались вводиться.

Объяснение этому обнаружилось на http://www.openbsd.ru и показалось мне весьма странным: для ввода русских букв требуется обязательное наличие подходящей клавиатурной раскладки Xmodmap в каталоге /usr/X11R6/lib/X11/xinit или в домашнем каталоге пользователя.

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

Однако в данном конкретном случае без Xmodmap ничего не получалось. И файла-то такого в штатном комплекте не было вообще. Благо, отыскать его мне удалось по ссылке с того же http://www.openbsd.ru. Скачав соответствующий файл, поместив его в /usr/X11R6/lib/X11/xinit и переименовав, соответственно описанию в файле /usr/X11R6/lib/X11/xinit/xinitrc, в .Xmodmap, я получил, наконец, возможность вводить русские буквы...

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

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

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

! Key Base Shift Caps ShiftCaps
!----------------------------------------------------------------------
keycode 9 = Escape NoSymbol Escape
keycode 10 = 1 exclam exclam 1
keycode 11 = 2 at quotedbl 2
keycode 12 = 3 numbersign grave 3

и так далее. То есть

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

!
! Key Base Shift Caps ShiftCapsM
!----------------------------------------------------------------------
keycode 9 = Escape NoSymbol Escape
keycode 10 = 1 exclam 1 exclam
keycode 11 = 2 at 2 quotedbl
keycode 12 = 3 numbersign 3 numbersign

и далее по всем пунктам. Впрочем, для Windows-раскладки этого можно и не делать. Я столь непосильную работу произвел. Его следует просто разместить в соответствие с описанием в файле /usr/X11R6/lib/X11/xinit/xinitrc, имеющем вид:

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/usr/X11R6/lib/X11/xinit/.Xresources
sysmodmap=/usr/X11R6/lib/X11/xinit/.Xmodmap

то есть либо в каталоге /usr/X11R6/lib/X11/xinit/, либо в своем домашнем.

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

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

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

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

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

set meta-flag on
set convert-meta off
set output-meta on

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

cat > имя_файла
содержимое файла
Control+D

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

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

Однако и это - дело поправимое. Для этого всего-то и нужно, что вписать в профильный файл bash (/.profile или $HOME/.profile, по потребностям) следующее:

export LESSCHARSET=latin1

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

Русских букв в X Window мы добились в прошлом разделе. Но только - в оконном менеджере, запускаемом по умолчанию, через startx. Так как только в этом случае исполняется сценарий из файла /usr/X11R6/lib/X11/xinit/xinitc и, соответственно, считывается файл .Xmodmap. Если запустить X Window в чистом виде (командой xinit) и в дальнейшем - какой-либо оконный менеджер из командной строки терминала - никаких русских букв ввести с клавиатуры не удасться (хотя созерцать их на экране - это пожалуйста).

Определенная сложность возникнет (вернее, просто потребуются некоторые дополнительные действия) при использовании WindowMaker'а. Как известно, первому его запуску (любым способом) должно предшествовать исполнение инсталляционной программы - wmaker.inst от лица пользователя. Каковая создает в его домашнем каталоге, во-первых, необходимые служебные подкаталоги, и, во-вторых, собственный файл $HOME/.xinitrc.

Файл этот, разумеется, не содержит никаких указаний на размещение Xmpdmap, А поскольку при запуске X'ов командой startx, вместо системного xinitrc исполняется именно он, русские буквы с клавиатуры в WindowMaker загадочным, на первый взгляд, образом исчезают.

Чтобы вернуть их на место, нужно, во-первых, скопировать в свой домашний каталог файл .Xmodmap, во-вторых, явным образом вписать путь к нему в файл $HOME/.xinitrc.

Впрочем, можно поступить и проще - просто вписать в конец системного xinitrc строку

exec wmaker

закрыв комментариями прочие ранее использовавшиеся по умолчанию оконные менеджеры и снеся напрочь пользовательский $HOME/.xinitrc. Я лично поступил именно так - вписал в xinitrc под ремарками все симпатичные мне оконные менеджеры и снимаю комментарии с того из них, который гармонирует с моим сегодняшним настроением.

Проблема иного рода возникает с XFce. Эта оконная среда, основана на библиотеке Gtk и, как и все известные мне Gtk-приложения, относится к категории правильных. То есть сведения, необходимые для поддержки национальных языков (NLS) она берет из системной локали.

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

Более того, это - общее свойство всех Gtk-приложений для OpenBSD: и Blufish, и GIMP, и прочих. И, что характерно, только их: программы, основанные на библиотеке Qt или вариациях Motif/LessTif/OpenMotif, ничего подобного не обнаруживают, Исправно подставляя кириллические шрифты туда, куда нужно. Если, конечно, знают о существовании русской локали вообще. Замечу также к слову, что в Linux я не замечал за Gtk-приложениями такого безобразия. Хотя, как говорят, во FreeBSD положение с ними то же, что и в OpenBSD.

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

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

Индикаторов раскладки клавиатуры мне известно не так много (интересно, а для консоли есть ли они вообще? в DOS, помнится, для этой цели изобретались всякого рода цветные экранные рамки...). Это, во-первых, штатный индикатор из KDE - kikbd, который, правда, мало чего индицирует и ничего не переключает; подчистую подчас уничтожая, зато, все настройки XF86Config на кириллицу. Так что о нем говорить не буду.

Есть еще индикатор переключатель из русской редакции Linux Mandrake - kkb, достаточно удобный, но уж очень, на мой взгляд, маленький. И к тому же требующий библиотеки Qt. Удобен, по слухам, переключатель Ивана Паскаля (xxkb), позволяющий, в частности, запоминать его положение для каждого окна отдельно (как Windows 95 и выше). Но с ним я пока дела не имел.

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

Программа эта существует в исходных текстах и написана под Linux, однако без труда компилируется в под OpenBSD. Все, что для этого нужно - распаковать архив, войти в каталог с исходниками и, если предполагается использовать fookb с WindowMaker, дать команду make. После чего скоприровать образовавшийся исполнимый файл fookb в подходящее место (например, в /usr/local/bin), а все файлы с расширением *.xpm (их четыре) - в каталог /usr/local/share/fookb (предварительно его создав).

Если же требуется применять fookb в иных оконных менеджерах, следует предварительно открыть Makefike, закрыть комментарием строку

#FLAGS=-DWMAKER

и, напротив, раскомментировать строку

#FLAGS=

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

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

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

xterm -fn -cronyx-courier-*-r-normal-*-20-*-*-*-*-*-*-*

Правда, вводить символы кириллицы непосредственно в командной строке нельзя - вместо них выводятся их коды. Но это, на мой взгляд, и не нужно. А вот для просмотра файла с русским текстом командами less или cat этого более чем достаточно. Как и для броузинга русских html-документов через lynx.

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

Единственная из используемых мной программ, которая потребовала несколько более радикальных телодвижений - это Lyx. Однако и здесь принципиальных сложностей не возникает. Нужно только разжиться файлами koi8-r.kmap и cyrillic.bind (все, нужное для русификации Lyx, также можно взять у меня). Первый помещается в $HOME/.lyx/kbd, второй - в $HOME/.lyx/bind. Подкаталог же $HOME/.lyx/ сам собой образуется при первом запуске программы, если согласиться с ее предложением это сделать (отказываться от чего - решительно не вижу причин).

После этого в подкаталоге $HOME/.lyx файл lyxrc.default переименовывается (хотя и не обязательно, но так - лучше) в lyxrc. И в нем вносится минимальная правка. А именно, строка

font_encoding "T1"

заменяется на группу строк
font_encoding "koi8-r"
screen_font_encoding koi8-r
ind_file cyrillic

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

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

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

Тем не менее, установить его (стандартным образом, из коллекции пакетов в ~/cdrom/2.8/packages/i386) стоит. И даже согласиться поначалу. что по умолчанию будет использоваться американский английский язык (в дополнение к чему можно применить и английский английский, а также немецкий и французский).

После чего следует озаботиться поисками словаря русского. Его, говорят, можно скачать по ссылке с www.opennet.ru. Мне, однако, это не удалось - пришлось взять исходники с одного из оказавшихся под рукой Linux-диска УрбанСофт, каковые были благополучно скомпилированы обычным образом (через make и make install).

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

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

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

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

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

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

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

Это - отнюдь не в упрек OpenBSD. А скорее призыв к разработчикам - больше внимания уделять таким прозаическим вещам, как поддержка родной (и чужой) речи.

Тем более что и существующее положение - отнюдь не безнадежно. И в первом приближении OpenBSD может использоваться для работы с русским языком. Что я попытался продемонстрировать в этой заметке. Которая к стати, как и все предыдущие на эту тему, написаны именно в этой системе и ее средствами.

Обновлено: 13.03.2015