Bsd операционная система. Чем FreeBSD отличается от Linux

При проектировании корпоративной IT-системы необходимо определиться с кругом решаемых задач и с требованиями по безопасности, быстродействию и надежности. Эти характеристики напрямую зависят от выбора операционной системы (ОС), устанавливаемой на сервере. Свободно распространяемые UNIX-подобные системы BSD и GNU/Linux постепенно вытесняют привычный Windows. Они более безопасны, поскольку доступ осуществляется по принципу «все запрещено, что не разрешено», поэтому они практически не подвержены вирусным атакам, обладают высокой производительностью и надежностью.

Операционные системы семейства BSD

Система распространения программного обеспечения Berkeley Software Distribution (BSD) была создана в начале 90-х годов выпускниками Университета Беркли (Калифорния). Разработчики UNIX-подобной операционной системы 386BSD выложили исходники в открытый доступ, на их основе были написаны базовые ОС:

• BSD/OS, коммерческая версия.
• NetBSD, open-source.
• FreeBSD, open-source.

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

Семейство BSD:

• FreeBSD – проект нацелен на создание простой в управлении системы с высокой производительностью.
• DragonFlyBSD - высокопроизводительная масштабируемая ОС предназначена для поддержки многопроцессорной обработки данных (SMP), создана из проекта FreeBSD;
• NetBSD – поддерживает максимальную переносимость кода для разных вычислительных ресурсов; поддерживает устаревшее оборудование; эту ОС использовали в космических проектах NASA.
• OpenBSD – надежная ОС с повышенным уровнем безопасности создана на базе проекта NetBSD; ее устанавливают в банках и государственных учреждениях США .

Отдельно можно отметить TrueOS (ранее PC-BSD) - операционная система, основанная на FreeBSD и ориентированная для использования на рабочих станциях.

Самая распространенная – FreeBSD, она установлена у 80% пользователей , остановивших свой выбор на семействе BSD.

В режиме online доступна подробная документация в разных форматах по настройке и управлению системой.

На FreeBSD приложения можно установить двумя способами:

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

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

Операционные системы Linux

Linux, в отличие от BSD, является только ядром ОС. Добавлением к ядру GNU-программ формируются ОС GNU/Linux со своим набором прикладных и системных компонентов. Дистрибутивы Linux распространяются в виде инсталляционных пакетов бесплатно или за умеренную цену; можно скомпилировать систему из исходных кодов.

Основные линукс-дистрибутивы:

• Debian – один из первых дистрибутивов.
• Ubuntu – самый популярный линукс, созданный на базе Debian.
• Fedora – поддерживается компанией RedHat.
• RHEL – коммерческая версия линукса Fedora.
• Gentoo – полностью собирается из исходных кодов, можно гибко настроить систему.
• Mint – совместим с Ubuntu, содержит Java и AdobeFlash.
• Slackware – старейший линукс.
• Arch – постоянно обновляемый дистрибутив, поддерживает бинарный формат и установку из исходных кодов.
• CentOS – основан на коммерческом дистрибутиве RedHat, стабильная серверная ОС.
• PCLinuxOS – портативный LiveCD дистрибутив.

Каждый линукс создавался под определенные задачи. Для установки Gentoo и Arch необходим богатый опыт в разрешении проблем с зависимостями и драйверами. Относительно просто устанавливаются дистрибутивы Ubuntu и Debian.

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

Сравниваем FreeBSD и Linux

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

И FreeBSD, и дистрибутивы семейства Linux являются UNIX-подобными операционными системами. Линукс изначально создавался Линусом Торвальдсом как свободная альтернатива UNIX-подобной системе MINIX, в то время как FreeBSD ближе к изначальной версии UNIX: первая ОС семейства BSD даже носила название Berkeley Unix.

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

Одно из основных отличий между семейством BSD и дистрибутивами, в основе которых лежит ядро Linux, состоит в типе лицензирования.

Большинство дистрибутивов Linux и приложений для них распространяются под лицензией GNU GPL, также известной как лицензия «copyleft» («авторское лево»), позволяющая использовать оригинальный код для создания новых продуктов, не запрашивая разрешения владельца исходных текстов, но сохраняя условия его распространения. Эта лицензия продвигает идею свободного распространения и открытости превыше всего. Поэтому при разработке проприетарного ПО стоит с осторожностью использовать продукты, лицензированные GPL.

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

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

Использование FreeBSD и Linux

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

Например, FreeBSD легла в основу следующих продуктов:

• FreeNAS - операционная система для сетевого хранилища.
• pfSense - дистрибутив межсетевого экрана.
• m0n0wal - дистрибутив встроенного межсетевого экрана.
• Darwin - ядро систем macOS, iOS.
• Junos - операционная система для сетевого оборудования от Juniper Networks.
• Isilon Systems’ OneFS - операционная система для сетевого хранилища от Dell EMC.
• Netflix Open Connect appliances - стриминговые серверы.
• Игровые консоли PlayStation 3, PlayStation 4, PlayStation Vita от Sony Computer Entertainment.
• и др.

На основе ядра Linux созданы:

• Android - операционная система для мобильных устройств (Google).
• Tizen - операционная система для мобильных устройств (Samsung).
• VMware ESXi - гипервизор.
• ChromeOS - операционная система для ноутбука Chromebook.
• ОС для одноплатных компьютеров Cotton Candy и Raspberry Pi.
• ОС для сетевого оборудования Linksys.
• и др.

Заключение

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

В ATLEX дистрибутив CentOS используется на серверах и серверах для предоставления услуги на базе Xen. Для облачных сервисов OpenStack применяется дистрибутив Ubuntu. А на FreeBSD работают некоторые служебные серверы.

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

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

В соответствии с данными, полученными от IOSC, в 1999 году практически треть всех машин, которые были подключены к интернету, работали на основе Linux, в то время как практически 15% применяли операционную систему FreeBSD. Что это за система, и по сегодняшний день знают лишь немногие современные пользователи ПК, несмотря на все ее преимущества и широкое распространение в свое время. Стоит отметить тот факт, что многие мировые лидеры в сфере Web-услуг активно работают на данной системе. В частности, стоит отметить, что на сегодняшний день система Yahoo основана на FreeBSD. Что это дает пользователям, сами они вряд ли знают и даже задумываются, но владельцы системы уверены, что это правильное решение.

Что представляет собой BSD?

BSD расшифровывается как Berkeley Software Distribution. Именно так в своем время называлось программное обеспечение, которое в Беркли распространял в исходных кодах. При этом стоит отметить тот факт, что изначально дополнение к стандартной операционной системе UNIX - это единственное, что представляло собой FreeBSD. Что это было по сравнению с нынешней версией системы?

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

Структура

Преимущества и особенности, которые имеет данная система, отличаются структурой FreeBSD. Что это за структура:

• Ядро, которое предназначается для тщательной планировки всех процессов, управления памяти, работы с различными устройствами, а также поддержки многопроцессорных систем. При этом следует отметить тот факт, что, в отличие от ОС Linux, в данном случае есть несколько типов ядер BSD, которые отличаются разными особенностями.
• Библиотека С, которая используется в качестве основного системного интерфейса программирования, причем основывается на коде из Беркли, а не из проекта GNI.
• Всевозможные файловые утилиты, компиляторы, оболочки, редакторы связей, а также другие программы конечного пользователя, при этом некоторые из них основываются на коде GNU.
• FreeBSD UNIX - операционная система, включающая в себя X Window, которая отвечает непосредственно за Данная система применяется в преимущественном большинстве версий BSD и официально поддерживается проектом X.Org. Данная система позволяет пользователю делать выбор из нескольких графических оболочек, а также целого ряда легких оконных менеджеров.
• Большое количество других системных и прикладных программ.

Что такое настоящий UNIX?

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

BSD - это UNIX?

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

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

В течение 80-х годов сформировалось несколько компаний, занимающихся производством рабочих станций, при этом стоит отметить, что многие из них приобретали лицензии на использование UNIX вместо того, чтобы пробовать разрабатывать с нуля собственное программное обеспечение. В частности, стоит выделить компанию Sun, которая поступила таким образом и решила на основе версии 4.2BSD в конечном итоге выпустить собственную операционку, которая называлась SunOSTM. Когда же компания AT&T, занимающаяся разработкой UNIX, в конечном итоге решила заняться коммерческой продаже собственной операционной системы, появилась довольно аскетичная реализация - System III, за которой с течением времени последовал также выход системы System V.

По какой причине эта операционная система остается невостребованной?

Есть некоторый ряд причин, по которым сегодня FreeBSD 10 пользуется не таким широким спросом:

• Разработчики чаще всего интересуются качеством собственного кода, причем больше его шлифовкой, а не рекламой.
• По большому счету, популярность Linux является следствием целого ряда внешних факторов относительно данного проекта, в частности, это касается средств массовой информации, а также компаний, которые решили сформировать собственный бизнес, предоставляя услуги пользователям этой операционной системы.
• Разработчики BSD в преимущественном своем большинстве являются более опытными по сравнению с разработчиками Linux, в связи с чем они гораздо меньше внимания уделяют тому, чтобы облегчить жизнь простым пользователям. Другими словами, настройка FreeBSD для обычного пользователя является более сложной, чем
• В 1992 году разработчик UNIX решил подать в суд на компанию BSDI, которая занималась поставкой операционной системы BSD/386. Основной пункт обвинения в данном случае был тем, что в ОС содержался закрытый код, принадлежавший истцу, и вроде бы дело в конечном итоге было улажено за пределами суда в 1994-м, но целый комплекс вторичных тяжб даже в наши дни отравляет жизнь многим людям.
• Есть мнение, что сами по себе проекты BSD различаются и при этом могут даже конфликтовать между собой. Данное мнение основывается на событиях, которые происходили достаточно давно.

Что лучше - Linux или BSD?

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

Кому принадлежит BSD?

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

Что все-таки выбрать?

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

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

Обеспечивает техническую поддержку, а также обслуживает FreeBSD - порты и системы - компания FreeBSD Mall, Inc.

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

История BSD Unix началась с того момента, когда в 1974 году в Университет Беркли (Калифорния, США) попала операционная система Unix. К тому времени эта ОС уже несколько лет за символическую плату распространялась лабораторией Bell Technical Labs (BTL) среди университетов и других учебных заведений, успев завоевать симпатии пользователей, которым пришлась по душе открытость системы: Unix поставлялась в исходных текстах (без поддержки и гарантий BTL), и пользователи имели возможность самостоятельно изучать, исправлять и расширять ее. Все это порождало желание делиться своими наработками с другими энтузиастами Unix и во многом сформировало специфический образ мышления и Unix-культуру. Надо заметить, что сотрудники Bell Technical Labs поступили очень мудро (возможно, даже не осознавая этого), отпустив Unix в свободное плавание. Свобода оказала услугу как самой системе, так и ее пользователям - на Unix выросло немало профессионалов, не говоря уж о количестве дипломов, защищенных по связанным с этой ОС темам. Так что можно считать, что ОС Unix вступила в коммерческий мир с полным университетским образованием. Кстати, совсем недавно на подобный шаг - передачу исходного кода учебным заведениям - решилась фирма BSDI. Интересно, повторится ли история?

Но вернемся в Беркли. Именно там родились многие идеи, ставшие теперь общепризнанными - поддержка протокола TCP/IP в ОС Unix, система виртуальной памяти, быстрая файловая система (FFS), редакторы ex и vi, BSD sockets (интерфейс программирования сетевых приложений), sendmail, csh и многое другое. Университет также дал миру прекрасных специалистов, которые во многом определили развитие Unix - достаточно вспомнить Эрика Аллмана, Билла Джоя или Чака Хейли. Именно к ним первым попали тексты Unix, "поселившиеся" в Беркли. Разработкой Unix здесь занималась группа Computer System Research Group (CSRG), которая, к сожалению, распалась в 1992 году. Однако лучшие ее традиции были продолжены компанией BSDI (Berkeley Software Development, Inc.) и группами разработчиков FreeBSD и NetBSD. Совсем недавно к ним добавилась команда проекта OpenBSD.

1. Все началось с 386BSD

В то время по миру бродило несколько версий BSD Unix, но все они имели нечто общее: для их использования требовалось обладать лицензией на первоначальный исходный код Unix. Большая часть кода BSD была написана в Беркли, и однажды кто-то заметил, что собственно оригинального кода осталось не так уж и много; так родилась идея создать свободно-распространяемый Unix и начать его распространение через Сеть (Net distribution).

Вильям и Линна Джолитц решили переписать части системы, недостающие для создания общедоступного варианта BSD Unix. В результате появилась 386BSD версии 0.0. Еще не готовая к использованию, 386BSD обладала одним несомненным достоинством: для того чтобы создать работоспособный вариант системы, больше не требовалось внушающей ужас source license. Вскоре появилась 386BSD 0.1 (к тому времени Linux, другой член семейства бесплатных систем Unix, существовал уже более года). Многие люди, желая повозиться с исходным кодом, с которым они уже были знакомы ранее, решили начать использовать и исправлять 386BSD 0.1. В результате начиная с июня 1992 года в систему было внесено большое количество исправлений и улучшений. На многих серверах FTP существовал даже неофициальный patchkit (набор исправлений), который позволял сделать 386BSD более стабильной и удобной в применении - многие затруднения в работе системы решались именно с помощью patchkit. Но сегодня, после возникновения некоторых юридических проблем с частью кода, принадлежащего AT&T/Berkeley, оригинальную систему стало довольно трудно найти - она была удалена с FTP-серверов по всему миру.

Следует вспомнить, что, когда некоммерческое семейство BSD только создавалось, Вильям и Линна в качестве основы использовали ленту под названием Berkeley Net Release/2. Выстроив таким образом прочный фундамент, они также заложили, сами не желая того, бомбу замедленного действия. В результате юридических битв часть файлов исходной ленты Net/2 была обозначена как binary only. Следовательно, они должны были быть воссозданы с нуля, чтобы получить истинно свободно-распространяемую систему. В этом и заключается основная причина того, что сейчас найти оригинальную версию 386BSD version 0.1 практически невозможно. Для того чтобы заменить 386BSD, родилось три новых системы под новыми именами. Первой была NetBSD, вскоре за ней последовала FreeBSD, а совсем недавно к этой группе прибавилась OpenBSD.

Если взглянуть на файл README, поставляемый с каждой BSD-системой, можно обнаружить, что эти системы базируются на BSD 4.4-Lite. Команда разработчиков FreeBSD использовала BSD 4.4-Lite distribution и создала недостающие части кода; все это после дальнейшего развития и превратилось в FreeBSD. Разработчики NetBSD начали разработку с 386BSD, добавив также доступные части из BSD 4.4. Система OpenBSD в свое время отделилась от NetBSD - разработчики решили объединить лучшие черты FreeBSD (удобство работы и функциональность) и NetBSD (переносимость на большое количество платформ). Таким образом, команды разработчиков Open/Free/NetBSD заново создали те файлы, которые отсутствовали в оригинальном комплекте BSD 4.4-Lite или не могли распространяться свободно. Все системы максимально приближены к BSD 4.4, хотя у каждой имеются свои преимущества и недостатки.

Рассмотрим эти системы более подробно, однако сразу стоит заметить, что очень часто многое, сказанное об одной системе, подходит и к другой: все эти ОС OpenBSD, FreeBSD и NetBSD развиваются раздельно, но не изолированно.

2. NetBSD

NetBSD Project - это результат попытки большой группы энтузиастов создать свободно-распространяемый вариант Unix-совместимой операционной системы. NetBSD основана на большом количестве свободно распространяемого программного обеспечения, в первую очередь BSD4.4-Lite Университета Беркли. Система работает на множестве платформ - от DEC Alpha до Apple Macintosh и z80, поставляется с полным исходным кодом и поддерживается самими разработчиками системы и пользователями. Основную ставку разработчики сделали на надежность и поддержку большого количества платформ. Пожалуй, сегодня едва ли найдется аппаратная конфигурация, где нельзя было бы установить NetBSD.

Реализация проекта началась в январе 1993 года, и уже к апрелю появился первый официальный выпуск - версия 0.8, которая работала еще только на платформе i386. За ней последовала версия 0.9 в августе того же года. Первоначально NetBSD была унаследована от 386BSD, которая использовала Berkeley Net Release 2 (BNR/2) и, естественно, как и другие операционные системы на базе BNR/2, в какой-то момент столкнулась с трудностями. Только через год после выпуска 0.9, в октябре 1994-го, появляется NetBSD 1.0 - первая версия NetBSD, которая базируется на BSD4.4-Lite. Помимо этого, система была портирована на HP300/9000, Macintosh, PC532, Sun SPARC и Amiga. В сентябре 1995 года создается NetBSD Foundation, некоммерческая организация, призванная стать координирующим органом NetBSD Project. Вскоре (ноябрь, 1995) NetBSD портируется на Atari, DECstation, VAX, Sun3; в нее добавляется двоичная совместимость (в пределах одной платформы) с FreeBSD, iBCS2, SunOS, Ultrix, HPUX, Linux, OSF/1, SVR4. Версия получает номер 1.1. Самой свежей версией NetBSD стала реализация 1.2 (октябрь, 1996), а наряду с множеством усовершенствований и изменений появилась поддержка платформ DEC Alpha, Motorola MVME boards, SPARC/Sun4m.

Система NetBSD распространяется в двух вариантах: формальный выпуск и NetBSD-current. FreeBSD и OpenBSD имеют ту же схему. Формальный выпуск имеет номер версии и включает в себя хорошо отлаженные утилиты, ядро, исходных кодов и средства установки. Выпуск представляет собой баланс между возможностями и стабильностью - его легче установить, чем current-версию. Такие версии хорошо отлажены и появляются относительно редко, поэтому они подходят тем, кто желает иметь стабильно работающую систему. Эти версии удобнее в поддержке, поскольку всегда ясно, о чем идет речь. Самая большая проблема с формальными версиями заключается в том, что пользователь не получает доступа к базе исходного кода с последними улучшениями и исправлениями. Формальную версию несложно установить - для каждой платформы имеются детальные инструкции, образы загрузочных дисков или miniroot-файловых систем. Как правило, существует процедура, позволяющая легко перейти с предыдущей версии на новую.

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

NetBSD project стремится следовать таким стандартам индустрии, как POSIX и Standard C. Напомним, что POSIX (Portable Operation Systems Interface) - название финансируемой IEEE группы, которая разрабатывает стандартный API для Unix-подобных операционных систем. Существует POSIX.1 (IEEE Std1003.1-1990), который стандартизирует API для Си POSIX.2 (IEEE Std1003.1-1992), стандартизирующий работу оболочки и утилит. Другие POSIX-стандарты описывают языки Ада и Фортран, расширения для работы в реальном времени и т. д. Сейчас NetBSD очень близка к POSIX.1, поэтому перенос программного обеспечения в среду NetBSD - несложная задача. Но вряд ли когда-нибудь NetBSD получит статус системы, соответствующий POSIX, поскольку сертификация стоит немалых денег. Тем не менее разработчики считают, что NetBSD ближе к POSIX и Standard C, чем какая-либо другая свободно распространяемая операционная система.

3. FreeBSD

Проект FreeBSD родился в начале 1992 года и частично вырос из проекта "Неофициальный набор исправлений для 386BSD" или, точнее, из patchkit, возглавляемого Нейтом Вильямсом, Родом Граймсом и Джорданом Хаббардом. Кроме того, в разработке участвовали Дэвид Гринмэн и Джулиан Элишер, хотя официально они присоединились к проекту только через месяц после начала его реализации. Поскольку организация работы через patchkit уже не могла спасти положение, главной целью проекта было создание промежуточного варианта 386BSD, в котором была бы исправлена большая часть ошибок. Возможно, кто-то сейчас еще может вспомнить рабочие названия проекта типа 386BSD 0.5 или 386BSD Interim, которые отражали текущее положение дел.

Примерно в это время Билл Джолитц отказался от дальнейшей поддержки и развития системы, в результате чего проект модернизации 386BSD превратился в то, что мы знаем теперь под названием FreeBSD (имя было придумано Дэвидом Гринмэном). Джордан Хаббард обратился в Walnut Creek CDROM (США) в надежде открыть дополнительные каналы распространения для еще не созданной операционной системы. Компания Walnut Creek CDROM не просто поддержала идею распространения FreeBSD на CD - она еще помогла с компьютерной техникой и скоростным подключением к Internet. Первый CD-диск с FreeBSD появился в декабре 1993-го - это был FreeBSD 1.0, версия которого тоже распространялась по Сети. Система была основана на ленте 4.3 BSD Lite (Net/2) из Беркли и дополнена компонентами из 386BSD и от Free Software Foundation. Для первой версии успех был довольно значительным, и вскоре, в мае 1994-го, на свет появилась очень удачная версия 1.1.

Однако затем на горизонте стали сгущаться тучи. Компания Novell - наследник AT&T - начала тяжбу за запрещение использования фрагментов кода в ленте Berkeley Net/2, которые вели свое происхождение из AT&T. Университет Беркли был вынужден выпустить "облегченный" вариант, названный BSD4.4-Lite, и порекомендовать всем пользователям Net/2 переключиться на него. Поэтому в конце июля 1994 года FreeBSD project прекращает поставку FreeBSD, но, в соответствии с лицензионным соглашением, имеет право на выпуск еще одной версии до наступления "часа Х". В итоге появляется FreeBSD 1.1.5.1 - результат года работы на Net/2. Эта версия обладала лучшей производительностью, чем все предыдущие, имела более высокую надежность и сама по себе была прекрасным продуктом.

Но теперь разработчикам предстояло фактически начать все заново, основываясь на новом и неполном наборе BSD 4.4-Lite. Из-за различных юридических ограничений команда Berkeley CSRG удалила большое количество кода, используемого для создания загружаемой работоспособной системы, и фактически порт на Intel x86 оказался очень неполным. FreeBSD Project вновь начал работу в декабре 1994-го, и уже в январе 1995 года FreeBSD версии 2.0 появилась в Сети и на CD. Несмотря на некоторые шероховатости, система имела большой успех, и вскоре за ней последовала более быстрая и удобная в установке FreeBSD 2.0.5, выпущенная в июне 1995 года.

В конце этого года на свет появилась версия 2.1, очень стабильная, во многом усовершенствованная, которая по всем параметрам превосходила версию FreeBSD 1.1.5.1. За два года была проделана огромная работа по превращению неполного набора BSD 4.4-Lite в работающую, надежную и удобную операционную систему. Нельзя не восхищаться командой разработчиков, к которой к тому времени присоединились многие прекрасные программисты-энтузиасты. Чуть позже 2.1 превратилась в 2.1.5, затем в 2.1.6. В обоих случаях повышена стабильность, добавлены дополнительные драйверы, исправлены найденные ошибки. В феврале 1997-го в системной библиотеке была обнаружена неточность в обработчике переменной окружения PATH_LOCALE, и тогда команда разработчиков FreeBSD удалила версию 2.1.5/2.1.6 со всех FTP-серверов и выпустила версию 2.1.7 (security-release). Затем вышла версия 2.2 и начались работы над FreeBSD 3.0, где намечается повышение качества работы виртуальной машины (VM), что позволит улучшить эмуляцию DOS и Windows-приложений.

Кроме того, совсем недавно был начат грандиозный проект по построчному перебору всего кода FreeBSD (около 120 Мбайт). Цель проекта - избавиться от проблем с security, исправить обнаруженные ошибки и улучшить общий стиль. Дерево исходного кода было разбито на отдельные части, которые просматриваются различными командами программистов; все исправления неоднократно перепроверяются независимыми специалистами. Все это позволяет надеяться, что FreeBSD станет более защищенной системой. Кстати, проанализировав список рассылки BUGTRAQ за последние полгода, можно заметить, что коммерческие ОС типа Solaris, IRIX, не говоря уже о NT, существенно превосходят FreeBSD по количеству ошибок в программах, критичных для безопасности. Дополнительную информацию о FreeBSD Audit Project можно найти по адресу: http://www.freebsd.org/auditors.html .

Таким образом, разработка FreeBSD не представляет собой закрытый процесс, а напротив, поддерживает многолетние традиции сотрудничества специалистов из разных стран мира, работающих над одной задачей. Самые активные из разработчиков переходят в команду FreeBSD core team, которая занимается общим направлением и целевой координацией проекта.

4. OpenBSD

Проект OpenBSD отделился от NetBSD совсем недавно и также является членом семейства BSD4.4-Lite. Сегодня OpenBSD развивается самостоятельно; кроме собственных разработок в него включаются удачные идеи от других групп (FreeBSD/NetBSD). Разработку OpenBSD начал Тео де Раадт, один из четверых создателей NetBSD. И если раньше про OpenBSD еще можно было сказать: "OpenBSD - это NetBSD плюс дополнительные возможности", то сейчас, после долгой работы, очевидно, что OpenBSD является самостоятельной системой из семейства BSD - очень многое, по сравнению с оригинальной версией, было добавлено и исправлено.

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

OpenBSD совместима со многими расширениями FreeBSD (в частности системой FreeBSD ports); недавно появилась поддержка ATM, ведется работа над включением IPX и ряда других сетевых протоколов. Одно из главных достоинств OpenBSD - это понимание необходимости защищенности системы. Система OpenBSD остается практически самой надежной в этом плане Unix-подобной системой для ПК. Последняя версия OpenBSD - 2.0, а в ближайшее время появится версия 2.1 (на CD и серверах FTP).

5. Возможности Net/Free/OpenBSD

Итак, что же сегодня представляет собой семейство свободно распространяемых BSD Unix-систем?

FreeBSD - Unix-подобная операционная система для ПК, основанных на архитектуре Intel, включающей в себя 386-е, 486-е и Pentium-процессоры. Кроме того, ОС NetBSD/OpenBSD поддерживают множество других платформ. Все три системы предоставляют много возможностей, которые ранее были доступны только на более мощных и дорогих машинах.

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

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

Поддержка TCP/IP-сетей включает в себя SLIP, PPP, NFS и NIS. Это означает, что машина может с легкостью взаимодействовать с другими системами, например выступать в роли сервера предприятия, обеспечивающего такие жизненно важные функции, как NFS, e-mail, WWW и FTP-сервер, управление маршрутизацией с использованием встроенных брандмауэров.

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

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

Двоичная совместимость со многими программами, построенными под SCO, BSD/OS, Net/Free/OpenBSD, 386BSD и Linux.

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

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

Разделяемые библиотеки (эквивалент DLL, заимствованных MS Windows из Unix) позволяют эффективно использовать дисковое пространство и оперативную память.

В комплект BSD Unix включен полный набор средств разработки на Си, C++ и Фортране. Кроме того, через коллекцию FreeBSD ports and packages доступно немало других сред разработки.

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

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

6. Особенности реализаций

В дополнение к основной поставке FreeBSD предлагает большую коллекцию портированных программных продуктов из нескольких сотен наименований. Список включает сетевое программное обеспечение, системы программирования, игры и многое другое. Полная коллекция занимает только 10 Мбайт на диске, поскольку хранятся лишь списки изменений, которые необходимо произвести в исходных текстах перед компиляцией. Для установки достаточно набрать команду "make", после чего система автоматически заберет базовую версию программы с CD или с сервера FTP, произведет необходимые изменения и скомпилирует. Для тех, кто не собирается компилировать программы самостоятельно, подойдет коллекция уже готового программного обеспечения (packages). Для установки программы необходимо набрать единственную команду "pkg_add" с именем архива, который можно найти на CD или на FTP.

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

7. Примеры использования

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

Поскольку исходный код систем полностью доступен, система может быть настроена и/или адаптирована для решения конкретных проблем, что обеспечивает гибкость, отсутствующую у многих коммерческих закрытых систем. Вот лишь некоторые примеры использования FreeBSD, NetBSD или OpenBSD:

Internet-сервер: быстрая и надежная реализация TCP/IP делает BSD Unix идеальной платформой для серверов FTP, World Wide Web, Gopher, электронной почты, BBS и Usenet;

обучение: BSD Unix поможет будущим администраторам в изучении архитектур операционных систем и сетевых возможностей аппаратных конфигураций;

исследования: BSD Unix, обладая полным исходным кодом, может служить хорошей платформой для исследований и разработок в области операционных систем. Этому также способствует отсутствие лицензионных ограничений;

сети: FreeBSD или Open/NetBSD могут с легкостью превратить старый компьютер 386/486 в DNS-сервер или мощный маршрутизатор с возможностью фильтрации пакетов;

рабочая станция для X Window: BSD Unix может неплохо послужить в качестве недорогого X-терминала. Благодаря свободно-распространяемому XFree86-серверу можно работать и с коммерческими X-серверами. В отличие от обычного X-терминала BSD Unix позволяет X-приложениям работать локально, снимая нагрузку с сервера. BSD Unix поддерживает удаленную загрузку, облегчая администрирование;

разработка программного обеспечения: базовая система BSD Unix поставляется с полным набором инструментов, которые включают в себя компилятор GNU C/C++ и отладчик.

BSD Unix, как правило, не включает код поддержки DES, чтобы не нарушать экспортные ограничения США, где доступен дополнительный компонент, обеспечивающий DES; для жителей Европы и других стран также существует реализация DES, распространяемая через европейские FTP-серверы. Если защита паролей - единственное, что требуется от функции crypt(), и не нужно использовать пароли в других системах (Sun, DEC и т. д.), то FreeBSD предлагает надежную криптографическую защиту, основанную на MD5. Данная модель обеспечивает защиту на уровне DES, а то и превосходит его, поэтому она устраивает большинство пользователей системы. OpenBSD поддерживает MD5, ведутся работы по добавлению модели шифрования blowfish. ОС FreeBSD также двигается к реализации дополнительных схем шифрования, между которыми можно будет переключаться.

8. BSD/OS - коммерческая BSD-система

До сих пор основное внимание уделялось свободно распространяемым BSD-системам, однако имеет смысл упомянуть также коммерческую версию BSD/OS компании Berkeley Software DesingBSD/OS. Несколько ведущих специалистов CSRG организовали в 1991 году BSD Inc., чтобы развивать технологию BSD и донести ее до коммерческих заказчиков.

BSD/OS - полнофункциональная, POSIX-совместимая Unix-система для процессоров архитектуры 386, 486 и Pentium. Система основана на программном обеспечении Университета Беркли, а также других источниках и компонентах, разработанных в BSDI. Первая версия BSD/OS была поставлена заказчику в марте 1993 года. Сегодня BSDI Internet Server, основанный на BSD/OS, широко известен в своем классе систем и имеет несколько наград (например, InfoWorld Top Score Award в 1995 г.). Как и другие BSD-системы, данная ОС может служить WWW-сервером, маршрутизатором и т. д. BSDI Internet server несет в мир ПК многое из того, что раньше было возможно лишь на более мощных системах: многозадачность, поддержка сети. Так, тесты скорости BSDI показали, что BSD/OS на Intel 486/66 развивает скорость на уровне Sun SPARCStation II, а Pentium-процессор сравним уже с SUN SS10.

BSD/OS включает в себя все компоненты полноценной системы: X11R6, TCP/IP (+SLIP/PPP), NFS, средства разработки на C/C++, набор приложений и др. BSD/OS поставляется в двоичном виде, а за отдельную плату - с исходными текстами. Пожалуй, единственное, в чем BSD/OS безусловно обгоняет своих бесплатных конкурентов - это поддержка. BSD/OS - коммерческий продукт, и его пользователям доступны "горячие" телефонные линии, к их услугам отделы поддержки и т. д.

9. Так что же лучше?

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

Но сегодня положение изменилось. Пользователь имеет возможность приобрести ПК, который будет в несколько раз мощнее многопользовательских VAX, и при этом выбрать из нескольких свободно распространяемых операционных систем (BSD, Linux и т. д.) Классический вопрос: если нечто выглядит, как утка, прогуливается, как утка, и крякает, как утка, как это называется? Ответ зависит от того, является ли слово "утка" торговой маркой! Если это так, то самое лучшее, на что вы можете рассчитывать без согласия владельца торговой марки, это "уткоподобное существо". Unix является торговой маркой X/Open Company, поэтому остальные системы, которые не имеют права на ее использование, именуют свои продукты Unix-подобными или даже "UN*X-like". Поэтому ни одна из перечисленных ОС формально не может называться Unix, но разве они стали от этого хуже?

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

Вы можете выбрать ту операционную систему, которая больше подходит: FreeBSD, OpenBSD, Linux, NetBSD или что-то иное. Но что бы вы ни выбрали, это удачная сделка. Многие небольшие фирмы, Internet-провайдеры, другие организации и пользователи отказываются тратить деньги на то, что можно получить бесплатно, и все чаще используют свободно распространяемые системы семейства Unix. Вы боитесь, что не сможете найти необходимого программного обеспечения? Во-первых, к вашим услугами Internet, во-вторых, можно приобрести программное обеспечение под BSD/OS и/или Linux и использовать его на своей системе - двоичная совместимость хорошо отлажена. Кроме того, многие коммерческие разработчики поворачиваются сейчас в сторону свободно распространяемых BSD-систем.

Литература

В. Колонцов. Найти, проверить и обезвредить. Открытые системы. - 1996, # 6, сс. 58-63.

Дополнительная информация об операционных системах семейства BSD

386BSD - старые версии BSD сегодня ориентируются исключительно на академическое и исследовательское сообщество, распространяются через Dr. Dobb"s Journal на CD-дисках.

FreeBSD - версия BSD для платформы Intel ориентируется на широкое использование, распространяется на CD (Walnut Creek CD-ROM, http://www.cdrom.com ) и через FTP (http://www.freebsd.org ).

BSD/ OS (BSDI Internet Server) - коммерческая BSD-система от Berkeley Software Development, Inc. для Intel-платформ (http://www.bsdi.com ).

Usenet groups: comp.Unix.bsd.* Fidonet: ru.Unix ru.Unix.bsd IRC: #netbsd, #freebsd, #openbsd etc.

ОС BSD жила, живет и будет жить

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

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

И еще: далее ни слова не будет говориться о применении Linux или FreeBSD в качестве серверов, узлов локальной сети и тому подобных сисадминских материях. А исключительно – о пользовательских, сиречь десктопных, их качествах. Предвидя реакцию некоторой категории читателей, последнюю фразу готов выделить тэгом и повторить дважды и трижды:–) Субъективное вступление

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

В периоды, когда на моей машине одна FreeBSD, рабочее время мое распределяется примерно так: 90% – практическая работа (абсолютно не важно, какой характер она носит в данный момент), и 10% – более или менее нездоровые эксперименты над системой. Стоит же угнездиться в уголке винчестера какому–никакому Linux–у – и временная доля экспериментов сразу подскакивает до 50%. А в периоды, когда я занимался сборкой Linux–а с нуля, экспериментальный режим фактически становился перманентным.

И я задал себе вопрос – почему? И – для себя же – ответил: FreeBSD – цельная и стройная система, в которой после комплекса начальных настроек не возникает желания ни прибавить чего, ни убавить. Не случайно движение , время от времени охватывающее широкие слои Linux–пользователей, в мире FreeBSD фактически не получило развития: известное сочинение Йенса Швайкхардта (существующее и в ) – это скорее описание автоматизированной альтернативы sysinstall, нежели ручного построения собственной системы с нуля.

Linux такую внутреннюю стройность продемонстрировать не может. И потому желание что–то изменить в уже установленной системе, усовершенствовать, добавить, почистить, а то и просто пересобрать все заново, возникает постоянно, и преодолевается только дефицитом времени.

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

Однако повторяю, все это – сугубо субъективно, ведь далеко не все занимаются сочинением околокомпьютерных заметок. И потому попробую провести более объективное сравнение.Первая попытка объективизма: «железо»

Что требуется большинству пользователей от операционной системы как таковой? Во–первых, конечно поддержка «железа», которое на настольных персоналках, как известно, однообразием не страдает.

Бытует мнение, что Linux поддерживает более широкий спектр оборудования, нежели FreeBSD. Действительно, для последней мы не найдем, скажем, принтерных драйверов от производителя. Полноценная поддержка современных видеокарт реализована только в том случае, если они от NVIDIA (да и то, по отзывам, существенно худшая, нежели для Linux–а). Вероятно, возникнет в этой ОС напряженка и с т.н. win–модемами. Это с одной стороны.

А с другой: всем счастливым обладателям контроллеров ATA RAID и Serial ATA в Linux до недавнего времени приходилось прибегать ко всякого рода ухищрениям. К тому же не всегда удачным, особенно если присоединенные к таким контроллерам диски предполагалось использовать в качестве загрузочных устройств. Собственно, ситуацию можно считать нормализовавшейся только в последних ядрах ветки 2.6.X...

Во FreeBSD же 5–й ветки более или менее параллельно, на каком контроллере IDE–семейства сидит жесткий диск: благодаря CAM (Common Access Method) как–то работать с ним можно будет в любом случае, а если он еще и корректно опознан, то не будет препятствий и для загрузки с него. Да и в 4–й ветке – я ни разу не сталкивался с проблемами для «одновозрастных» контроллеров ATA RAID.

Другой пример – звуковые карты. Все те из них, что основаны на более–менее распространенных чипах, работали во FreeBSD без малейшего напряжения (рук или мысли). То же можно сказать и о «чипсетном» звуке. В Linux–е же аналогичные устройства часто требовали не вполне тривиальных манипуляций с ALSA–драйверами, благо ныне они встроены в ядро. Однако даже и в последнем случае без кое–каких настроечных действий не обойтись. Но это уже предмет второй попытки объективизма.

А итог «железного» объективизма я сформулировал бы так: может быть, Linux поддерживает более широкий круг всяческого оборудования (в том числе, и кое–какой экзотики), но все «железо», что поддерживается FreeBSD (а это практически все стандартное и распространенное «железо»), использовать, в большинстве случаев, проще. И тут мы плавно переходим ко второму волнительному для юзера, особенно начинающего (а не начинающие давно сделали свой выбор) моменту, имя которому –Настройка

Устоявшее (и тщательно культивируемое) мнение, будто бы FreeBSD сложнее в установке и настройке, нежели Linux, я не могу объяснить ничем иным, как недоразумением. Потому что ничего общего с действительностью оно не имеет.

Начнем с установки. Инсталляция FreeBSD штатными средствами (с помощью утилиты sysinstall) выполняется за полчаса, не требует непременного доступа к Сети (хотя таковой лишним не будет) и дает в итоге полностью работоспособную систему с кириллической консолью, функционирующим dial–up (или, по ситуации, включением в локалку), запускаемыми Иксами и необходимым для начала практической деятельности минимумом пакетов (из прекомпилированных бинарников). Все настройки, и общесистемные, и для прикладных пакетов, разумны (пусть и не идеальны с точки зрения конкретного юзера).

Конечно, установка FreeBSD требует некоторых предварительно полученных знаний. Каковые сводятся к а) представлению о разметке диска в BSD–стиле, принятой здесь номенклатуре накопителей и стратегии создания файловых систем. Не потому, что эти моменты так сложны – просто именно они очень отличаются от всего, что пользователь мог знать ранее (по опыту общения с DOS/Windows или Linux). И к тому же разметка диска и файловые системы на них – это единственное, что пользователь не в силах изменить после инсталляции (без тотальной переустановки, естественно). Однако и это не столь страшно: предлагаемая в sysinstall схема разметки и файловых систем по умолчанию вполне походит для настольной персоналки, хотя и не идеальна в ряде специальных случаев.

Большинство известных мне инсталляторов из разных дистрибутивов Linux отличаются от Free"шного sysinstall в две противоположные стороны:

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

Наравне с Free–шным sysinstall я поставил бы (из всех мне известных) только установщик из Archlinux. Написанный, как свидетельствует его разработчик, под влиянием первого, он обеспечивает почти такое же сочетание простоты и гибкости.

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

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

Начнем с той же русификации. Сразу после установки FreeBSD пользователь, при желании, получает полностью кириллизованную консоль. Правда, в одном–единственном варианте, с внутренней кодировкой kOI8–R, вводом в ней же и экранным выводом в кодировке DOS, да еще и с не вполне идеальными шрифтами. Но никаких дальнейших действий по базовой русификации от него в обязательном порядке не требуется. А привести раскладки и шрифты в соответствие со своим идеалом он может и позднее. В дистрибутивах же Linux, не очень напирающих на дружественность пользователю ручной правки пары конфигов, пожалуй, не избежать. На причинах этого останавливаться не буду (для тех, кто представляет разницу между консолью в Linux и FreeBSD, они очевидны).

Конечно, в user–ориентированных дистрибутивах Linux отечественного происхождения пользователь получает стопроцентно русифицированную консоль «из коробки». Однако выполненную в соответствии с представлениями разработчиков. Каковые отнюдь не обязаны совпадать с представлениями (и, главное, потребностями) данного конкретного пользователя. И в этом случае на коррекцию ему придется затратить существенно больше сил, нежели при русификации с нуля какого–либо дистрибутива из числа Source Based. В подтверждение чему – вспомним многочисленные статьи, посвященные откату в Red Hat (и Fedore"ном Core) с «прогрессивной» кодировки UTF на KOI8, пусть «бомжовскую», но вполне устраивающую многих и многих...

Русификация консоли тесно связана со стилем инициационных файлов, принятых в данной системе. И тут линейный BSD–стиль с позиций пользователя выглядит более простым, нежели принятая в Linux инициация в стиле System V, основанная на понятии runlevels , перевод которого как «уровни выполнения» способен окончательно запутать начинающего пользователя.

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

Не случайна тенденция многих современных дистрибутивов Linux к использованию BSD–стиля загрузки, примерами чему, кроме классической Slackware, и CRUX, и Gentoo. А в Archlinux понятие runlevels вообще утрачивает значение, хотя соответствующие слова в файле /etc/inittab найти можно, на практике уровни выполнения при старте системы никак не играют. А вот попыток внедрить в BSD–системы «прогрессивный» стиль System V что–то не наблюдается. Не считать же таковым группировку скриптов различных служб в едином подкаталоге в /etc во FreeBSD 5–й ветки.

Что до русификации Иксов – X, как известно, он и в Африке X. И действия по вписыванию путей к файлам с кириллическими шрифтами, коррекция клавиатурной раскладки и установка переключателя с латиницы на кириллицу окажутся неизбежными, поверх какой операционки Иксы бы ни стояли.

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

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

В Linux: начинаем с того, что то же самое чипсетное аудио (а с постепенным вымиранием карт типа SB AWE128 оно становится предпочтительным для всех пользователей без претензий на меломанию или композиторство) непременно требует драйверов ALSA. Благо, что ныне они встроены в ядро и в большинстве дистрибутивов включены в умолчальные ядра в качестве модулей. Если нет, то перекомпиляция ядра большого труда не составит.

Однако перекомпиляцией ядра дело не ограничивается. Нужно еще поставить соответствующий ALSA–инструментарий (да еще, как правило, средства совместимости ее со старой звуковой системой OSS), активизировать соответствующего демона и с помощью не вполне очевидных средств обеспечить его «самовосстановление». И после всего этого опять столкнуться с неожиданностями. Например, с нежеланием мирного сосуществования ALSA и arts (звуковой системы KDE). Конечно, мне могут возразить, что это проблемы KDE, однако во FreeBSD их не возникает вовсе.

Кстати, о доустановке инструментария (и прочих программ)... Для этого ведь необходимаСистема управления пакетами

Здесь до недавнего времени первенство, безусловно, принадлежало FreeBSD. Система портов ее обеспечивала несравненное сочетание простоты и гибкости, всегда оставляя возможность выбора – собирать ли пакеты из исходников, или устанавливать их из бинарников. Не возбраняя и комбинацию этих методов. Из всего Linux–ового богачества по этой части с портами мог сравниться только Debian–овский apt, ассимилированный в недрах многих rpm–based дистрибутивов. Однако, хотя apt и предполагает возможность сборки собственных пакетов, основным методом при нем является использование прекомпилированных бинарников, собранных в соответствие с представлениями майнтайнера о зависимостях оных.

Ныне положение изменилось и в Source Based дистрибутивах Linux широко используются портообразные системы, развившиеся под сильным влиянием своего FreeBSD–прототипа: портежи Gentoo, Sorcery из Sorcerer"а, порты CRUX, Archlinux Building System из одноименного дистрибутива. Они подчас превосходят своего прародителя по универсальности, гибкости, глобализации настройки или прозрачности устройства, использования и модернизации. К тому же, за десятилетие своего развития порты FreeBSD стали весьма громоздким и труднообозримым сооружением, поддержание которого в актуальном состоянии представляет собой отдельную задачу. Далеко не всегда решаемую с помощью дополнительных средств типа portupgrade (которая сама по себе является уже частью не базовой системы, но системы портов).

И тут уместно сказать пару слов еще об одной широко распространенной легенде – будто бы сборка из исходников посредством портообразных управляющих комплексов всегда приводит к более «чистой» (то есть свободной от лишних компонентов) системе. Это далеко не всегда так.

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

Что меня всегда удивляло в портах FreeBSD, так это ситуация со сборкой моего любимого редактора joe. Каковой в качестве зависимости непременно требовал GNU make версии 3.80, хотя собственный make входит в состав FreeBSD Distributions и собрать с его посредством joe руками не составляет никаких проблем.

А вообще «чистота» установки пакета очень зависит от конкретной реализации порта. Недавно обнаружил я в новостях сообщение о новом оконном менеджере под названием edo – небольшом, как говорилось, компактном и быстром. Обнаружился он и в портах FreeBSD, откуда я решил его собрать. В итоге этот маленький:–) WM потянул за собой (как зависимость зависимости) не что иное, как MySQL...

Однако если вы думаете, что такое поведение портов – особенность FreeBSD, и создатели их Linux–клонов учли ошибки прошлого, то уверяю это не всегда так. Причем в Linux ситуация усугубляется особенностями базовой системы, точнее, несогласованностью развития отдельных ее компонентов.

Каждый, кому доводилось собирать Linux from Scratch, знает, что некоторые версии пакетов Base Linux имеют обыкновение собираться только с определенными (отнюдь не обязательно самыми свежими) версиями таких утилит, как autoconf и automake, категорически отказываясь делать это с другими их версиями (пусть даже более свежими и прогрессивными).

Разработчики Source Based дистрибутивов Linux подчас обходят эту сложность тем, что принудительно вносят в список зависимостей таких «склизких» пакетов autoconf и automake «прошлогоднего» розлива, притом, что сам по себе базовый комплект включает уже текущие на данный момент их версии. В результате чего, например, в Gentoo при выполнении бутстраппинга или emerge system можно с удивлением наблюдать, как система лезет в Интернет за бородатым, как Карл Маркс, autoconf хотя свежая его версия только что была развернута из тарбалла stage1. А если вспомнить, что многие полагают, будто по настоящему стабильное ядро Linux может быть собрано только с gcc версии 2.9.X, результатом чего оказывается присутствие в системе двух компиляторов, то о какой «чистоте» сборки можно еще говорить?

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

• FreeBSD, вопреки устоявшемуся мнению, существенно проще в настройке и локальном администрировании. Даже без учета того факта, что она одна, а Linux–ов – много;
• напротив, система портов FreeBSD в настоящее время (в отличие от недавнего прошлого), не имеет значимых преимуществ перед аналогичными инструментами из Source Based дистрибутивов Linux.

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

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

Для пользователя, отдающего преимущество работе в графическом режиме, разницы между FreeBSD и Linux практически нет.

Ибо такой пользователь большую часть времени проводит в Иксах, и ему абсолютно без разницы, поверх какой операционки эти самые Иксы крутятся. Ему только кажется, что он работает в Linux или FreeBSD (NetBSD, OpenBSD – рискну расширить я этот список). На самом деле работает он в KDE (Gnome, XFce, WindowMaker – нужное дописать). И если бы ему не пришлось предварительно устанавливать и настраивать свою операционку, он имел бы шанс никогда не узнать, в какой именно из POSIX–совместимых систем он работает: перед ним будут одни и те же интерфейсные элементы, одни и те же средства настройки и приложения.

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

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

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

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

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

Так что же, в консольном режиме первенство остается за FreeBSD? По моему мнению – безусловно. Но только если речь идет именно о чисто текстовой консоли. Если же обратить свой взгляд на т.н. графическую консоль (реализуемую посредством Frame Buffer), то все видится несколько иначе.

Начать с того, что графическая консоль FreeBSD (т.н. Raster Mode) ограничена одним–единственным разрешением 800x600 (тут речь идет именно о настоящем пиксельном разрешении, а не плотности символов). Да и то на некоторых чипах этот режим не работает вообще, на других имеет вполне скверный вид. Собственно, нормального результата в Raster Mode мне не удавалось добиться ни на одной из имевшихся в моем распоряжении видеокарт.

В Linux же графическая консоль просто радует глаз. Даже при поддержке Frame Buffer для абстрактных VESA–совместимых карт, можно варьировать разрешения от 640x480 до 1280x1024, с изменением глубины цвета в стандартном диапазоне. Что обеспечивает не только комфортный просмотр изображений, но и весьма приличное (на мой взгляд – более чем приличное) воспроизведение видео. Для карт, имеющих хорошо реализованные собственные драйвера в ядре Linux (Matrox, ATI, чипсетное видео от Intel) к этому добавляется возможность установки нестандартных разрешений экрана.

Естественно, никто не использует консоль для работы с изображениями, и очень немногие для просмотра видео. Почему же я придаю графической консоли такое значение? Да потому, что незаметно, но наступает эра жидкокристаллических дисплеев, знаменующая собой смерть чисто текстового режима (но не консольного режима как такового). Почему – легко поймут те, кто видел стандартный текстовый режим 80x25 символов на 18–дюймовом LCD–мониторе с физическим разрешением матрицы 1280x1024. А как это смотрелось бы на экране с соотношением сторон 16:9 я боюсь себе даже представить...

Наконец, остается еще один вопрос, важный для пользователя –О производительности

Представление о большем быстродействии FreeBSD по сравнению с Linux–ом столь же традиционно, как и мнение о большей сложности ее настройки. Однако так ли все однозначно?

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

Во–вторых, даже если считать скорость загрузки одним из критериев быстродействия, то превосходство перед Linux–ом обнаруживает только FreeBSD 4–й ветки. Пятая ветка грузится ровно столько же, сколько и любой дистрибутив Linux, задействующий файловую систему устройств devfs. Конечно, в благородном Linux–семействе можно подобрать таких представителей, которые грузятся еще дольше, но это очень дружественные к юзеру системы, отягощенные... изобилием стартовых сервисов (в частности, автоопределителем оборудования kudzu).

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

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

Выше упоминалось, что за счет CAM во FreeBSD (речь идет о 5–й ветке) достигается универсализм в работе с дисковыми контроллерами – у меня сложилось впечатление, что ей вообще безразлично, на каком конкретно контроллере сидит диск (лишь бы он опознавался BIOS"ом – но и это необходимо только для загрузки с него ядра). Однако за универсализм приходится платить. И, похоже, что в данном случае расплата наступает в виде снижения быстродействия дисковых операций – хотя достоверной информации по данному вопросу я не нашел, исходя из общих соображений, это выглядит похожим на правду.

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

В Linux принята другая модель работы с ATA–дисками: разные типы контроллеров имеют (или не имеют) собственную поддержку в ядре. Что исключает использование явно не поддерживаемых устройств, зато для поддерживаемых, судя по всему, обеспечивает большее быстродействие. Файловые системы (а Linux поддерживает в качестве нативных несколько их разновидностей) по умолчанию все (кроме, возможно, JFS) используются в полностью асинхронном режиме (async mode), когда и данные, и метаданные кэшируются в оперативной памяти.

В результате сочетания указанных факторов файловые операции осуществляются в Linux существенно быстрее, нежели во FreeBSD. Собственно, я всегда это подозревал, но только показало, насколько отставание FreeBSD 5–й ветки в этом плане существенно – положение не спасает даже механизм SoftUpdates, призванный повысить и надежность, и производительность манипуляций над файлами. К слову сказать – во FreeBSD 4–й ветки такого отставания ранее не наблюдалось, что косвенно подтверждает негативное влияние работы с дисковой подсистемой (усугубляющее деградацию именно синхронных операций) – в ней модель CAM не используется (по крайней мере, не использовалась, когда я ею пользовался). А вот в Linux с его исключительно асинхронным использованием файловых систем, по моим наблюдениям, зависимости скорости работы с файлами от производительности дискового железа почти нет.

Второе из обещанных исключений относится к операциям своппинга. Каковые в Linux и FreeBSD выполняются существенно по разному. Для установления чего достаточно посмотреть на вывод команды top в той и другой ОС при среднепользовательской нагрузке. В Linux можно видеть, что при достаточном количестве оперативной памяти процент использования swap–пространства стремится к нулю. Например, на моем ноутбуке с Linux (512 Мбайт памяти) в момент сочинения этих строк, при загруженном KDE, html–редакторе Quanta, konsole, двух экземплярах konqueror и работающем mplayer (воспроизводство mpeg и RealAudio), swap не задействован вообще. На десктопе с FreeBSD (1 Гбайт памяти) при той же нагрузке задействованная область подкачки меньше 10% почти не опускается.

Это связано с тем, что Linux прибегает к своппингу только при переполнении оперативной памяти, во FreeBSD же на диск в любом случае (даже при избытке RAM) выгружаются страницы памяти, к которым не было обращений в течение некоего промежутка времени. В сущности, оперативная память в этой ОС выступает в качестве своего рода кэша для области подкачки (точнее, для виртуальной памяти вообще). Что эффективно при ограниченном ее объеме и было оправдано в стародавние времена, когда процессоры были медленными, а памяти – мало. Ныне такая модель использования своппинга в некоторых ситуациях приводит к замедлению работы. Пример – KDE с большим количеством рабочих столов и периодическим переключением между ними, где такое замедление видно невооруженным глазом.

Все это обуславливает большее объективное (устанавливаемое тестами) и особенно субъективное быстродействие Linux по сравнению с FreeBSD. Хотя должен опять подчеркнуть – речь идет именно о десктопной сфере: на сильно загруженном сервере механизм кэширования FreeBSD может проявить свои сильные стороны, и скоростные соотношения между этими системами, возможно, в ряде случаев окажутся прямо противоположными.Подведем итоги

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

Чем подкупает FreeBSD – так это а) простотой установки, б) логичностью настройки и в) легкостью администрирования в локальном масштабе. Однако те же особенности (по крайней мере, большая их часть) характерны ныне и для лучших (по моему мнению) современных представителей Linux–семейства (CRUX и Archlinux, в какой–то степени – Gentoo). Хотя ожидать от них внутренней стройности и целостности FreeBSD, по понятным причинам, в ближайшее время не приходится.

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

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

Демон с пингвином – братья навек!

Введение

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

Под загрузкой операционной системы понимается запуск на исполнение специальной программы, которая называется образом ядра системы (или просто ядром). Образ ядра — почти обычный бинарный исполняемый файл. И специфика его запуска — только в том, что, если любые другие программы запускаются под управлением какой-либо ОС, считываясь с файловой системы, которую эта ОС воспринимает в качестве родной (native), то ядро обязано запуститься как бы само собой, без всякой операционки (ибо оно-то и есть операционка), и с носителя, о котором система ничего не знает (поскольку сама она еще не загружена). Не случайно в англоязычной литературы для процесса загрузки существует общепринятая метафора называется bootstrapping, что что столь же аллегорически можно перевести как «поднятие себя за шнурки своих ботинок». И хотя в реальной жизни такое не каждому удается, в мире POSIX-систем эта процедура осуществляется регулярно — и, как правило, успешно.

Образ ядра системы содержит все необходимое для чистого bootstrapping’а. Однако выполнить его таким образом можно только с носителя без файловой системы. И потому прямой запуск ядра, насколько я знаю, используется только при загрузке с дискеты. При обычном же старте ОС с винчестера в этом деле участвует и некая внешняя сила — специальная программа, называемая загрузчиком. Она загружает ядро системы, отвечает за определение оборудования, подгрузку объектных модулей (загружаемых модулей ядра) и монтирование корневой файловой системы (в режиме «только для чтения»). Ядро же тем временем запускает системные (то есть не связанные с исполняемыми файлами) процессы, управляющие виртуальной памятью, буферами, страницами памяти и т.д., вплоть до swapper’а, а по завершении — свой и первый «обычный» (то есть ассоциированный с исполняемым файлом на диске) процесс init (/sbin/init).

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

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

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

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

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

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

О загрузке и загрузчиках

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

На самом деле любой загрузчик включает в себя две или даже три относительно независимые части — даже если он распространяется в виде единого пакета, как Lilo или GRUB. Чтобы убедиться в этом, представим себе, как происходит запуск машины на «железном», так сказать, уровне (имеется ввиду — intel-совместимой персоналки, на иных архитектурах все обстоит несколько иначе).

Перво-наперво после включения питания запускается программа, прошитая в ПЗУ компьютера (BIOS). Она выполняет проверку железа, после чего отыскивает носитель, установленный в BIOS Setup в качестве первого загрузочного устройства (для определенности — винчестер), на нем — первый физический блок, содержащий так называемую главную загрузочную запись (MBR — Master Boot Record).

Содержимое MBR — это, во-первых, таблица дисковых разделов, тех самых четырех, в один из которых мы ранее установили DragonFly. А во-вторых — некий код, принимающий на себя управление от BIOS по окончании его работы. В стандартном MBR — том, что записан на «свежевкрученном» винчестере или восстанавливается после DOS-команды FDISK /mbr , — этот код только и может, что отыскать первый физический раздел диска (primary partition) и передать управление на его загрузочный сектор. Чего вполне достаточно для загрузки операционок вроде DOS или Windows 9X/ME с первого (или единственного) раздела. Но явно мало в любом другом случае — например, если на диске установлено несколько ОС, которые, естественно, не могут уместиться в одном разделе.

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

Подобно MBR, загрузочный сектор раздела (Boot Record — уже не Master!) содержит информацию о его разметке (Disk Label), зависящие от используемой в данной ОС ее схемы, и управляющий код, принимающий эстафету от программы, записанной в MBR. И этот код — вторая составная часть загрузчика. Правда, и ее возможности также не могут быть богатыми — ведь размер загрузочного сектора раздела составляет те же 512 Кбайт. И потому на нее возлагается одна-единственная функция — передать управление программе, лежащей за пределами загрузочного сектора. Которая, собственно, и должна опознать корневой раздел ОС и несомую им файловую систему, после чего, прямо или опосредованно, загрузить ее ядро.

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

Стадии загрузки

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

Должен покаяться — за несколько лет общения с FreeBSD и эпизодическим знакомством с ее сестрами (OpenBSD и даже NetBSD) у меня как-то не было повода разбираться с устройством их загрузчика. Ну грузит он прекрасно родную систему — и замечательно (например, FreeBSD). Грузит также и другие BSD-системы — еще лучше. Что без напряга и Linux может загрузить — так вообще здорово. А то, что еще и на загрузку Windows способен — это уж просто бесплатное приложение…

Как и пребывал бы я в счастливом незнании, если бы как-то, в связи с установкой FreeBSD на ноутбук Toshiba, не пришлось покопаться немного с опциями BSD Loader. И тут оказалось, что это — программа с мощными интерактивными возможностями, да еще и обладающая возможностью настройки. Не сравнить с GRUB’ом, конечно, но если не экспериментировать с многочисленными операционками на многих винчестерах, — функций loader’а оказывается более чем достаточно. Что я и попытаюсь продемонстрировать ниже на примере ОС DragonFlyBSD. Однако почти все сказанное имеет силу и для всех других BSD-систем (а для FreeBSD — и без оговорки «почти»).

Основная особенность загрузчика DragonFly (хотя почти все сказанное имеет силу и для всех других BSD-систем — а для FreeBSD и без оговорки «почти»), отличающая его от Lilo и, в меньшей степени, GRUB, — то, что он не маскирует свою многокомпонентную природу, включая четыре (почти) самостоятельные программы.

Первая часть загрузчика (т.н. boot0) — это программа, записываемая при инсталляции системы в загрузочный сектор диска, с которого осуществляется загрузка машины согласно установкам BIOS. Обычно это Master на первом IDE-канале (о SCSI-дисках здесь речи не будет), но возможны варианты (например, при наличии аппаратного ATA RAID или дополнительных ATA-контроллеров). Эта программа отвечает за первую стадию этапа загрузки, а которой происходит чтение таблицы первичных дисковых разделов, вывод их списка (если разделов более одного), некоторого периода ожидания для выбора пользователем (по умолчанию загрузочным будет раздел, выбранный в предыдущем сеансе работы) и после такового (или по истечении фиксированного периода ожидания), передачи управления коду, записанному в загрузочном секторе выбранного (или умолчального) раздела. Выбор раздела осуществляется нажатием клавиш F1 —F4 ). Если дисков два, нажатие клавиши F5 просто передаст управление на загрузочный сектор второго из них — а там уж события потекут в зависимости от того, что в нем записано: читать разделы на втором физическом диске boot0 сам по себе не способен.

Список разделов для выбора включает их имена в соответствии с идентификаторами типа файловой системы, например:

F1 DOS F2 Linux F3 BSD F5 Drive 1

До недавнего времени BSD Loader не мог ни опознать логические разделы внутри Extended DOS, ни загрузить с них какую-либо операционку. Однако ныне положение, видимо, изменилось: это можно заключить из сообщений о возможности установки DragonFlyBSD в расширенный раздел (единственной, насколько мне известно, из BSD-систем, на это способной). А можно ли представить себе установку системы без возможности ее загрузки штатными средствами?

В принципе наличие первой части BSD-загрузчика не является обязательным: его вполне может подменять загрузчик Linux (тот же Lilo, передающий управление на загрузочный сектор BSD-слайса «по цепочке») или мультисистемный GRUB, который напрямую способен работать с файловыми системами и загружать ядра разных операционок.

Вторая часть (boot1) размещается в загрузочном секторе первичного раздела, несущего BSD-систему (BSD-слайса). То есть и boot0 , и boot1 лежат не только за пределами файловой системы, но и, фактически, вне собственно слайса BSD. Третья же часть (boot2) лежит уже внутри слайса, но не входит в какой-либо из его логических разделов.

Вторая и третья части загрузчика — это, в сущности, единая программа, разделенная только из-за ограничений на размер загрузочного сектора раздела (512 байт). Так что в задачу boot1 входит только опознать слайс BSD, отыскать на нем boot2 и передать ему управление. А уж тот обязан, выждав некоторое время, опознать корневую файловую систему, отыскать на ней и запустить бинарный исполняемый файл — /boot/loader , образующий четвертую часть загрузчика; строго говоря, термин BSD loader только к этой программе и относится.

Таким образом, можно видеть, что первые три части BSD-загрузчика (boot0 , boot1 и boot2) лежат вне файловых систем установленной ОС BSD. В которую мы попадаем только начиная с запуска loader , обычного исполняемого файла, помещаемого в специальном каталоге /boot корневой файловой системы.

Правда, в каталоге /boot (это — «умолчальное» место размещения loader) наряду с его исполняемым файлом можно видеть также файлы с именами boot0 , boot1 и boot2 . Но они представляют собой лишь копии соответствующего кода, расположенного (и запускающегося) вне файловой системы BSD. Назначение их — восстановление возможности загрузки после аварийных ситуаций.

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

1. Boot DragonFly — нормальная загрузка ядра со всеми положенными (кем и где положенными — разговор впереди) модулями, монтированием файловых систем и отработкой предписанных стартовых скриптов;
2. Boot DragonFly with ACPI disabled — то же самое, только с выключением модулей acpi , что иногда может потребоваться на некоторых ноутбуках;
3. Boot DragonFly in Safe Mode — загрузка в безопасном режиме, то есть без подключения модулей;
4. Boot DragonFly in single user mode — загрузка в однопользовательском режиме, при котором монтируется (да и то только для чтения) лишь корневая файловая система, а этап инициализации игнорируется;
5. Boot DragonFly with verbose logging — обычная загрузка, но с выводом подробных сообщений;
6. Escape to loader prompt — выход в командную строку загрузчика;
7. Reboot — ну, это мы знаем, как три пальца, только еще лучше.

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

После выбора или истечения срока давности начинается довольно длительный процесс определения оборудования, в ходе которого на экран выводятся многочисленные сообщения ядра — их отличие от обычных сообщений — в ярко-белом «окрасе» символов. Сообщения эти очень интересны, но рассмотреть их нелегко. Что, впрочем, не страшно — в дальнейшем их можно будет просмотреть командой dmesg . После этого монтируется корневая файловая система и с нее (обычным исполняемым файлом /sbin/init) запускается процесс init, отрабатываются стартовые скрипты. В ознаменование этого ярко-белый цвет сообщений ядра сменяется на обычный сероватый — этап загрузки, интересующий нас в данный момент, закончен.

Интерактивное управление процессом загрузки

Возникает вопрос — может ли пользователь повлиять на процесс загрузки? Ответ на него будет положительным. В ходе работы загрузочной системы пользователю трижды предоставляется свобода выбора: выбора загрузочного раздела на начальной стадии boot0 , выбора интерактивного управления на стадии boot2 и выбора режима загрузки сразу после запуска loader ‘а. И во всех этих случаях пользователь может вмешаться в процесс руками. Зачем? Это уже другой вопрос, и ответ на него, надеюсь, станет ясным из последующего изложения.

С выбором раздела загрузки все ясно: он позволяет загрузить одну из ОС, если на данной машине их установлено несколько. А вот на стадии работы boot2 можно прервать его исполнение, точнее — избежать запуска loader ‘а. Для этого в паузе между выбором загрузки с BSD-раздела и появлением сообщений о загрузке ядра и модулей (пауза эта знаменуется появлением на экране мигающего символа _) нужно нажать любую клавишу. В ответ последует приглашение вида:

>> BSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot:

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

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

• номер диска в машине в соответствие с понимаем BIOS (0 — первый из наличных, 1 — второй, и так далее, вне зависимости от порядка подключения);
• его интерфейс — в примере ad символизирует ATA диск (для SCSI диска было бы da , для дискеты — fd);
• номер на IDE-канале (0 — мастер, 1 — слейв);
• раздел в смысле, используемом BSD Label, то есть часть слайса, резервируемая под корневую файловую систему BSD (a ;
• имя файла образа старого ядра — /kernel.old .

Если на диске имеется несколько первичных разделов разных типов, то разделы не-BSD типа будут пропущены, и литера a (очевидно, что образ ядра может лежать только на корневой файловой системе) будет относиться к первому подразделу слайса с идентификатором 165 (даже если на диске он будет четвертым по счету).

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

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

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

Итак, выбрав пункт шестой меню — Escape to loader prompt , — мы оказываемся в среде командного интерпретатора loader ‘а. Она имеет шелл-подобный интерфейс — команды с их опциями и аргументами вводятся после приглашения, имеющего вид

С точки зрения удобства интерактивной работы — не GRUB, конечно: ни тебе автодополнения, ни истории команд, возможности редактирования ограничены клавишей Backspace . Но с главной своей ролью — вводом и исполнением встроенных команд, — loader вполне справляется.

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

Встроенные команды loader ‘а можно разделить на три части по их назначению:

• для получения информации;
• для конфигурирования загрузчика;
• собственно для управления процессом загрузки.

Из первой группы команд отметим следующие: ls , lsdev , lsmod , show , more . Первая предназначена для просмотра корневой файловой системы и ее подкаталогов, — правда, только тех, что которые не лежат на отдельных подразделах. Но поскольку все нужные для загрузки файлы лежат в подкаталогах непосредственно корня (в /boot , /dev , /modules), это ограничение не существенно. Вариант команды ls -l выводит список файлов (и каталогов) с указанием их размера — без этой опции только литерой d помечаются каталоги.

Команда lsdev выводит список дисковых устройств, имеющихся в машине, их первичных разделов и подразделов (последние — только для разделов, размеченных по правилам BSD Label). Опция -v обеспечивает детализацию вывода.

Команда lsmod обеспечивает просмотр модулей, загруженных loader ‘ом до появления меню (или приглашения командной строки). Как и в предыдущем случае, имеется опция детализации — -v .

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

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

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

Сначала рассмотрим команды управления модулями. Это — пара команд load и unload для загрузки и удаления модулей, соответственно. Первая используется с аргументом имя_модуля, каковое при необходимости можно подсмотреть (с помощью ls) в каталоге /modules — имя в аргументе дается без суффикса *.ko . Команда unload с аналогичным аргументом удалит указанный модуль, без аргументов — удалит все модули вообще, позволяя начать конфигурирование с чистого листа.

Действие команд load и unload распространяется также на ядро в целом. Так, посредством команды

OK unload kernel

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

OK load kernel.old

загрузить ядро старое, трудоспособное.

Пара аналогичного назначения — set и unset , — существует и для переменными окружения загрузчика. Переменные эти служат для изменения текущего дискового устройства, указания расположения корневой файловой системы, определения путей к модулям ядра, отличным от умолчального /modules , и тому подобных вещей. Делается это командой set в соответствие с синтаксисом C-shell, например:

OK set currdev="disk1s1a"

Определяет текущее дисковое устройство в терминах «диск#_слайс#_раздел».

Допустимо несколько значений для одной переменной — они разделяются точкой с запятой. Например,

OK set module_path="/;/modules;mymodule_path"

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

Некоторые переменные просто разрешают или запрещают какие-то действия, и, соответственно, значения их булевы — YES или NO . Естественно, они нуждаются в детализирующих переменных, определяющих то, что ими было разрешено. Например, переменная

OK set userconfig_script_load="YES"

только разрешает исполнение пользовательских сценариев конфигурирования, а переменная

OK set userconfig_script_name="/boot/my.conf"

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

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

OK set boot_single

Определение переменной может отменяться командой

Unset имя_переменной

В некоторых случаях ее эквивалентом будет определение переменной с булевым значением NO или словом disable в имени.

Полный список встроенных переменных окружения загрузчика можно посмотреть на соответствующей man-странице:

$ man 8 loader

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

Опции команды boot конкретизируют режим загрузки. Например, команда

OK boot -s

вызовет загрузку в однопользовательском режиме. Это эквивалентно тому, как если бы выполнить ту же команду без опций, предварительно установив переменную boot_single .

Аргументы команды boot могут определять имя образа ядра, исполняемого сценария загрузки, и так далее. Тот же сакраментальный пример: команда

OK boot kernel.old

приведет к загрузке старого ядра, аналогично команде boot без опций после исполнения пары

OK unload kernel OK load kernel.old

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

Здесь было рассказано не о всех возможностях интерактивного режима BSD-загрузчика — только о тех, которые мне довелось применять. Более подробные сведения можно почерпнуть не только в man (8) loader , но и непосредственно чтением файла помощи:

$ less /boot/loader.help

И совсем не обязательно в процессе управления загрузкой — лучше сделать это заблаговременно.

Конфигурирование загрузчика

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

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

Правда, на первом этапе загрузки можно настроить не так уж и много, а именно:

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

Приведенным целям служит команда boot0cfg . Стоит помнить только, что ее использование связано с изменением Главной Загрузочной Записи (MBR), разрушение которой приводит к невозможности старта машины с диска. Вероятность запортить этой командой MBR чрезвычайно мала, да и страшных последствий не имеет. Однако (береженого бог бережет) — лучше держать под рукой инсталляционный диск DFBSD. Не для переустановки системы, конечно, но для восстановления загрузочной записи — это ведь большая спасательная дискета. А как — будет предметом следующей статьи цикла.

Итак, изменить время ожидания можно с помощью опции -t # , где # — значение в секундах (нулевое значение не допускается). С помощью опции -s # один определенный раздел диска делается загружаемым по умолчанию на веки вечные (а не тот, с которого был выполнен старт при последнем включении машины). Очевидно, что здесь допустимы значения 1-4 (по числу возможных первичных разделов) плюс 5 — передача управления на MBR второго диска. А опция -v даст нам более подробную информацию о результатах выполненной операции. Ну и, конечно, требуется аргумент — имя дискового устройства, MBR которого мы меняем. То есть команда

$ boot0cfg -t 30 -s 2 -v -f /boot/boot0.old ad0

модифицирует MBR первого IDE-диска (аргумент ad0) так, что 2-й его слайс станет умолчально-загрузочным, время на выбор раздела возрастет до 30 секунд, и выдаст отчет о результатах своей работы в виде примерно следующем:

# flag start chs type end chs offset size 1 0x00 0: 1: 1 0x83 850:254:63 63 13671252 2 0x80 851: 0: 1 0xa5 261:254:63 13671315 23438835 version=187.102 drive=0x80 mask=0xf ticks=30 options=packet,noupdate,nosetdrv default_selection=F2 (Slice 2)

Ах да, опция -f создаст копию текущей загрузочной записи в каталоге /boot ; правда, файл /boot/boot0 и представляет собой копию MBR свежеинсталлированной системы, но — для страховки еще один дубль не повредит.

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

$ $ boot0cfg -o update ad0

Ну а смысл прочих опций (и другие способы применения команды) можно уточнить у тети Мани: man (8) boot0cfg .

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

Так вот, параметры загрузки ядра положены сценарием инициализации загрузчика — /boot/loader.rc . На самом деле это своего рода пакетный файл, из которого вызывается несколько отдельных сценариев, но для нас сейчас это не существенно. А важно то, что положены умолчальные переменные окружения загрузчика и их значения в парном сценарию конфиге — файле /boot/defaults/loader.conf . В нем описываются и пути для поиска модулей, и имя ядра по умолчанию, и текущее дисковое устройство и корневая файловая система, и время задержки перед загрузкой — все то, что можно определить в качестве переменных окружения интерактивно. А еще в нем есть список всевозможных модулей ядра (вообще говоря, всех возможных ) и указывается, следует ли их загружать автоматически при старте, или нет.

Сам по себе /boot/defaults/loader.conf для редактирования не предназначен, а лишь показывает все возможные параметры загрузки и фиксирует их значения по умолчанию. И потому собственно целям настройки loader ‘а служит не он, а файл /boot/loader.conf .

Правда, сразу после установки системы мы такого файла в системе не увидим. Его нужно создать самому, перенести в него нужные опции из файла /boot/defaults/loader.conf и должным образом изменить их значения.

В настройке любой системы обычно проще показать, как она делается, чем рассказать об этом. И потому приведу в качестве примера свой /boot/loader.conf с некоторыми комментариями. Я человек простой, к излишествам не склонный, и потому файл этот у меня очень маленький.

Autoboot_delay="5" # Время ожидания перед автозагрузкой beastie_disable="YES" # Отмена вывода меню загрузчика usb_load="YES" # Загрузка модуля поддержки шины USB ugen_load="YES" # Загрузка поддержки USB-устройств вообще ums_load="YES" # Загрузка поддержки USB-мыши # Эти строки требуются, если соответствующие функции # не встроены в ядро жестко snd_pcm_load="YES" # Загрузка модуля поддержки звука snd_ich_load="YES" # Загрузка модуля звукового устройства # В примере - чипсетное аудио от Intel ICH#

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

Vesa_load="YES" screensave_load="YES" screensave_name="fire_saver"

А можно также загрузить и собственную splash-картинку (созданием коей, в формате *.bmp или *.pcx, и ее размещением в каталоге /boot следует озаботиться заблаговременно):

Splash_bmp_load="YES" bitmap_load="YES" bitmap_name="filename.bmp"

Обратим внимание на строку vesa_load , подгружающую модуль поддержки одноименного режима в консоли: она необходима для некоторых, графических, скринсейверов (например, приведенного в примере «пламени») и, конечно же, splash-картинок. Впрочем, поддержка VESA может быть встроена в ядро (см. цикла).

Приведенный пример не исчерпывает возможности по реконфигурации загрузчика — иные возможности можно почерпнуть из просмотра файла /boot/defaults/loader.conf . Нужно только иметь ввиду, что какие-то функции, обеспечиваемые подгружаемыми модулями, могут быть уже вкомпилированными в ядро — умолчальное или собственноручно собранное, — и дублировать их не нужно. То есть перед редактированием /boot/loader.rc неплохо свериться с текущей конфигурацией ядра. Для свежеустановленной системы она описана в файле /usr/src/sys/i386/conf/GENERIC , а для собственноручно собранного… впрочем, если вы уже собирали ядро, то лучше меня знаете, как называется файл его конфигурации, и что в нем вписано.

Скажу только пару слов о модулях поддержки файловых систем. Очевидно, что встраивать в ядро поддержку тех из них, что используются лишь эпизодически (типа msdos), нет никакого смысла: в этом случае для всех из них (включая и ext2fs) при компиляции ядра будут по умолчанию собраны и загружаемые модули. Однако и в загрузке этих модулей при старте необходимости нет (хотя соответствующие строки в файле /boot/defaults и имеются). При обращении к устройству с чуждой файловой системой необходимый модуль подгрузится автоматически. Это же касается и модулей поддержки таких устройств, как диски в оперативной памяти (md — Memory Disk), если, конечно, не предполагается старта системы именно с них.

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

Отыскать нужные модули легко — они содержат в своем имени компонент snd . То есть можно прибегнуть к команде типа

$ ls /modules | grep snd

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

В приведенном примере отменен вывод меню loader ‘а. Меню это описывается в файле /boot/beastie.4th , использование коего предписано в файле /boot/loader.rc строкой

Include /boot/beastie.4th

Разумеется, это не обязательно. Можно, напротив, переделать /boot/beastie.4th так, чтобы отдельные пункты меню отвечали собственным вариантам загрузки — например, с различными наборами подргужаемых модулей, для чего придется создать несколько альтернативных конфигурационных файлов для loader ‘а. Или — образов ядра, собранного с различными опциями. А если вы еще и вышивать умеете (пардон, рисовать ASCII-символами), то можно заменить украшающую меню стрекозу на что-то свое.

Задачи инициализации

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

В действительности это могут быть (и в разных системах действительно бывают) весьма разные программы. Более того, его можно подменить при интерактивном управлении процессом загрузки другой программой, например, командной оболочкой. Однако это сейчас не очень важно — рассмотрим только штатные задачи программы /sbin/init .

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

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

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

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

Наконец, третья непременная задача процесса init — так называемое получение терминала (запуск процесса getty), установку его свойств и подготовку к авторизации — вытеснение его процессом login. Выполнение этой процедуры также определяется параметрами из соответствующего конфигурационного файла.

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

Понимание это, однако, затрудняется тем, что и сценарии инициализации, и их конфигурационные файлы реализованы в разных ОС и их дистрибутивах очень по разному. Впрочем, это многообразие можно свести к двум стилям — BSD, все вариации на тему которого очень похожи друг на друга, и System V, каждый представитель которого оригинален по своему. Первый стиль инициации используется в операционках одноименного семейства. Стиль же System V преобладает в большинстве распространенных дистрибутивов Linux. Хотя последнее время и во многих из них (CRUX, Archlinux, Gentoo) все шире применяются BSD-подобные схемы инициации.

Инициализация DragonFly

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

В однопользовательском режиме загрузка происходит а) при выборе соответствующего пункта (Boot in single user mode ) в меню начального загрузчика, б) при задании команды boot -s в командной строке загрузчика (после выбора пункта его меню Escape to loader prompt ), и в) при обнаружении серьезных (неустранимых автоматически) нарушений целостности файловой системы в ходе ее проверки на первой стадии инициализации).

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

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

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

Между однопользовательским и многопользовательским режимами не лежит непреодолимой пропасти: переход из одного режима в другой возможен не только при рестарте машины, но и в ходе одного сеанса. Для немедленного перехода в однопользовательский режим служит команда

$ shutdown now

Возврат обратно в многопользовательский режим происходит по команде

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

Загрузка в многопользовательском режиме — и это отличительная особенность BSD-стиля, — потенциально влечет за собой доступность для запуска абсолютно всех системных служб и демонов: инициализирующие их сценарии (располагающиеся в каталоге /etc/rc.d) теоретически могут быть запущены из главного стартового сценария — файла /etc/rc . А вот какие из них будут запущены реально — определяется опциями его конфигурационного файла — /etc/rc.conf . Наличие пары главного стартового сценария и его конфигурационного файла — вторая отличительная особенность DragonFly (и вообще BSD-стиля инициации).

При установке DragonFly в каталог /etc на диске записывается некий умолчальный /etc/rc.conf , строки которого имеют вид

Servicename_enable="значение"

Переменная="значение"

Значение строк первого вида = «YES» или «NO». Легко догадаться, что они разрешают (или запрещают) запуск поименованного сервиса посредством соответствующего ему (и, как правило, одноименного) сценария из каталога /etc/rc.d . Значения же строк второго вида — это параметры, передаваемые командам, входящим в скрипты инициализации.

По умолчанию в DragonFly — и это тоже традиция BSD-систем, — в файле /etc/rc.conf разрешен запуск лишь минимально необходимого для начала работы количества системных служб. Большая же их часть обычно запрещена — или явным образом, указанием значения «NO», или по умолчанию (а откуда эти умолчания берутся — мы сейчас увидим). Так что включение необходимых пользователю демонов (например, той же консольной мыши) — дело рук самого пользователя.

Стартовые умолчания берутся из файла /etc/defaults/rc.conf , в котором описаны всевозможные (и все возможные) стартовые сервисы и их параметры (помните — подобную же пару «умолчального» и рабочего конфигов мы видели для программы loader). Файл этот не предназначен для прямого редактирования (хотя оно и не запрещено атрибутами его доступа). Вместо этого полагается отыскать в нем строки, относящиеся к нужным сервисам, перенести их в /etc/rc.conf и разрешить их запуск (или, напротив, запретить, если оный разрешен по умолчанию, но в данном случае не нужен). Уточняющие опции сервисов также берутся из /etc/defaults/rc.conf , переносятся в /etc/rc.conf и им приписываются нужные значения.

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

$ less /etc/defaults/rc.conf

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

Как все это происходит практически — проще рассмотреть на нескольких примерах. В статье про установку DragonFly было показано, что для настройки консольной мыши с USB-интерфейсом достаточно активизировать демона соответствующих устройств, вписав в файл /etc/rc.conf строку

Usbd_enable="YES"

Однако для всех прочих типов мышей требуется определение некоторого количества иных переменных. Каких — определить не сложно. Отправляемся в ранее открытый файл /etc/defaults/rc.conf и отыскиваем в нем строки, имеющие отношение к мыши — в данном случае удобно воспользоваться командой типа

$ grep mouse defaults/rc.conf

— и смотрим на вывод результата поиска:

Moused_enable="NO" # Run the mouse daemon. moused_type="auto" # See man page for rc.conf(5) for available # settings. moused_port="/dev/psm0" # Set to your mouse port. moused_flags="" # Any additional flags to moused. mousechar_start="NO" # if 0xd0-0xd3 default range is occupied in your # start like mousechar_start=3, see vidcontrol(1)

Из коего, собственно, и становятся очевидными дальнейшие действия. Сначала следует разрешить запуск мышиного демона — для чего в /etc/rc.conf вносится строка

Moused_enable="YES"

Команда /usr/sbin/moused (а включить поддержку мыши можно и из командной строки, но только в данном сеансе работы — об этом будет сказано чуть позже) в общем случае требует двух опций — указания протокола (это то, что описывается строкой moused_type) и порта подключения (сериального, PS/2, USB — шинные мыши, скорее всего, из употребления уже вышли). При описании протокола строка

Moused_type="auto"

подойдет для всех, насколько мне известно, современных грызунов с разъемами PS/2, хотя его можно указать точно — ps/2 . А вот для сериальных (и тем более шинных) мышей протокол следует обязательно задать в явном виде. Каком — смотрим в man (5) rc.conf или man (8) moused (я, грешным делом, об этих существах уже забыл).

Явное указание порта также необходимо только для сериальных и шинных мышей («Вы знаете тетю Маню? — Я знаю тетю Маню. — Вы верите тете Мане? — Я верю тете Мане. — Так вот, у нее и спрашивайте за таких зверей…»). Хотя если указать

Moused_port="/dev/psm0"

для PS-пополамной животины, вреда не будет ни малейшего.

Moused_flags=""

можно задать разнообразные опции, предусмотренные для команды /usr/sbin/moused , как то: эмуляцию средней кнопки для двухклавишных моделях (на скроллирующих мышах колесико работает аналогично средней кнопке), скорость реакции, акселерацию при перемещении курсора и так далее. За подробностями — опять же к Мане, к Мане, к Мане…

Ну а о строке

Mousechar_start="NO"

разговор уже был: если в качестве кодировки вывода используется KOI8-R, а ядро не пересобиралось, или пересобиралось без опции

Options SC_MOUSE_CHAR=0x3

умолчальное NO следует заменить на 3 . В любом ином случае она просто не нужна.

Как будет показано в следующей статье , одной из целей пересборки ядра было обеспечение поддержки графической консоли. Однако включения соответствующей опции в конфиг ядра мало — соответствующий видеорежим нужно еще активизировать. Это обеспечивается сценарием /etc/rc.d/syscons , исполняющим, в частности, команду vidcontrol, отвечающую за все, что имеет отношение к настройкам экрана. А свои параметры эта команда получает опять-таки из файла /etc/rc.conf . В частности, видеорежим определяется переменной

Allscreens_flags=""

для которой нужно определить соответствующее значение в виде MODE_#режима. Например, при желании иметь разрешение 800×600 и 32-битную глубину цвета эта строка примет вид

Allscreens_flags="MODE_277"

Теперь о заключительной стадии инициации — процессе получения терминала. Она контролируется записями в файле /etc/ttys , о котором вскользь упоминалось в статье про установку системы . Наличие специального файла для конфигурирования виртуальных терминалов — третье из важных отличий BSD-систем: в Linux, вне зависимости от стиля сценариев инициализации, принятых в конкретном дистрибутиве, настройка виртуальных терминалов описывается в общем конфиге процесса init.

Содержимое файла /etc/ttys выглядит таким образом (строки, описывающие терминалы, получаемые при модемном доступе на машину, я опускаю, как неактуальные):

Console none unknown off secure # ttyv0 "/usr/libexec/getty Pc" cons25 on secure # Virtual terminals ttyv1 "/usr/libexec/getty Pc" cons25 on secure ttyv2 "/usr/libexec/getty Pc" cons25 on secure ttyv3 "/usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure

Как можно видеть, это — простая база данных, поля которой имеют следующее содержание:

1. имя терминального устройства, имеющее значения console для так называемой системной консоли, и имя виртуального терминала (ttyv# , где # — порядковый номер) — для всех остальных;
2. процесс, запускаемый на данном терминале для его активизации; на системной консоли никакого процесса не запускается, ее роль (в первую очередь — место помещения системных сообщений) исполняет первый виртуальный терминал; на прочих же, кроме последнего (о котором будет отдельный разговор) таким процессом является стандартный getty;
3. тип терминала — по умолчанию для стандартного видеорежима 80×25;
4. статус терминала, определяющий, активизирован (on) или нет (off); «отрицательное» значение по умолчанию можно видеть в двух записях — первой и последней;
5. степень защищенности терминала; умолчальное значение secure предполагает, что данный терминал физически, так сказать, недоступен для злоумышленника, и потому на нем безбоязннно можно зарегистрироваться суперпользователю; если изменить его на unsecure , то авторизация root’а с данного терминала окажется невозможной; указание значения unsecure для системной консоли повлечет за собой необходимость задания пароля суперпользователя при загрузке в однопользовательском режиме.

Что тут подлежит изменению? Во-первых, тип терминала: в случае русификации консольного режима умолчальное значение cons25 следует заменить на cons25r ; впрочем, мы ведь это проделали сразу после установки, не так ли? При использовании отличной от стандартной плотности символов тип терминала также подлежит изменению. Например, если используется режим 80×30, здесь следует подставить cons30r . Полный список допустимых значений типов терминала можно посмотреть в файле /etc/termcap .

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

*.err;kern.debug;auth.notice;mail.crit /dev/console

с системной консоли в какой-либо файл (или даже в устройство /dev/null). Однако кое-что на консоли появляться все равно будет — например, сообщения о присоединении и отсоединении устройств горячего подключения (типа USB-накопителей или PC-карт).

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

это отнюдь не препятствует.Разумеется, количество виртуальных терминалов, активизируемых при старте системы, можно изменить в ту или другую сторону. Понятно, что для уменьшения их числа достаточно просто удалить или закомментировать «лишние» строки, а для увеличения — вписать недостающие по образу и подобию имеющихся (не забыв переименовать файлы соответствующих устройств). Только нужно иметь ввиду, что умолчальное ядро GENERIC поддерживает 16 виртуальных терминалов, минимум один из которых должен быть зарезервирован для запуска оконной системы X — вручную или автоматически. И еще — при увеличении числа виртуальных терминалов нужно озаботиться наличием файлов соответствующих устройств (вида ttyv#) — по умолчанию в каталоге /dev их «только» 12.

К слову, об Иксах. Пользователи Linux имеют возможность обеспечить авторизацию в графическом режиме (и автоматическую загрузку Иксов) простым методом — изменением runlevel по умолчанию. А как быть пользователям BSD-систем, понятия runlevel не имеющих, — тем, кто работает преимущественно в Иксах и кому надоело набирать команду startx ? Да все столь же просто: достаточно активизировать «иксовый» виртуальный терминал, заменив в последней приведенной строке off на on . Это повлечет за собой автоматическую загрузку менеджера графического входа в систему — xdm . Каковой, естественно, можно заменить его более пролдвинутым аналогом. Например, строка

Ttyv8 "/usr/local/bin/kdm -nodaemon" xterm off secure

Оборотная сторона инициализации системы — это ее останов или рестарт, различий между этими процессами практически нет. И отвечает за него команда shutdown , которая может быть дана от лица суперпользователя или члена группы operator. С опцией -h она вызывает останов машины, с опцией -r — ее перезагрузку. И еще команде этой требуется аргумент — время, когда останов или рестарт должны произойти. Впрочем, есть способ и мгновенного останова или рестарта:

$ shutdown -h now

$ shutdown -r now

соответственно.

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

Останов системы происходит в порядке, обратном ее инициализации. Сначала делается попытка корректного завершения всех пользовательских процессов отправкой им сигнала TERM . По истечении некоторого промежутка времени всем еще «живым» процессам отправляется сигнал KILL — для гарантированного их убиения. Затем стопорятся все стартовые сервисы и демоны. Наконец, содержимое дисковых кэшей записывается на диск (посредством команды sync), и размонтируются файловые системы. После этого обычно появляется сообщение о возможности безопасного отключения питания машины или оно отключается автоматически. При рестарте все происходит точно также, но после останова системы автоматически начинается перезагрузка машины.

Как уже говорилось, сценарии, отвечающие за запуск стартовых сервисов, находятся в каталоге /etc/rc.d . Большинство запускаемых ими программ — это так называемые демоны (daemon — Disk And Execution MONitor), нечто вроде резидентных программ, работающих в фоновом режиме в ожидании запроса на исполнение их функции (печати, отправки почты, обращения к ftp- или http-серверу, и так далее). В соответствие с этим запускающие их сценарии устроены по принципу start — stop . И если при инициации системы выполняется первая функция, то при ее останове, как легко догадаться, вторая.

Ход процесса останова системы определяется сценарием /etc/rc.shutdown . Назначение его — выполнить функцию stop в сценариях всех сервисов, запущенных из скрипта /etc/rc в соответствие с описанием, данным в /etc/rc.conf и /etc/defaults/rc.conf .