Стратегия DragonFly

Рейтинг брокеров бинарных опционов за 2020 год:
Содержание

Стратегия DragonFly

Генеральный путь для получения дистрибутива DragonFlyBSD, к сожалению (для обитателей необъятных просторов нашей Родины, в массе своей хорошим коннектом не избалованных) — один-единственный: из Сети. Правда, в утешение можно сказать, что там он доступен в нескольких вариантах.

Первый — это официальный релиз DragonFly, вышедший в июле 2004 г. и ныне по-прежнему доступный в виде bug-fix версии 1.0A на ftp-сервере проекта и ряде его официальных и неофициальных зеркал (список проверенных лично мною приведен в разделе ссылок Отличительная особенность официального релиза — то, что он собран посредством компилятора gcc старой, но надежной версии 2.95.X.

Второй вариант — это промежуточные стабильные версии, появляющиеся на тех же серверах с неопределенной периодичностью, но обычно не реже 2 раз в месяц. Стабильные версии, как и официальный релиз, собираются с помощью gcc-2.95.X .

Третий вариант — это текущие снапшоты проекта, выходящие очень часто (раз в несколько дней, иногда чуть ли не ежедневно). Они представлены двумя подвариантами: собранные gcc веток 2.95 и 3.4.X. В последнем случае используется обычно самая свежая версия компилятора (на момент сочинения этих строк — 3.4.3). Подвариант с gcc2 позиционируется как (полу-) стабильный, рассчитанный на практическое применение. Сборка же с gcc3 к реальному использованию не рекомендуется, предназначаясь для разработчиков и экспериментаторов. Однако, судя по личному опыту, и последний подвариант признаков какой-то особенной нестабильности обычно не обнаруживает. И к тому же более интересен с точки зрения тенденций грядущего. Так что я сформулировал бы это так: все снапшоты DragonFly стабильны, но некоторые стабильнее других. Хотя вероятность наткнуться на какой-либо неудачный снапшот из числа промежуточных и существует.

А вообще предубеждение против gcc 3-й ветки имеет исторические корни. Ведь на протяжении долгого времени она развивалась в основном в плане улучшения поддержки Си++, тогда как генерация чистого Си-кода не только не улучшалась, но, как считают многие авторитеты (среди коих — и Линус Торвальдс) даже ухудшалась. И потому критически важные программы операционок Unix-семейства, написанные на Си (а ядро и утилиты обрамления, как легко догадаться, попадают в их число), обычно рекомендовалось собирать посредством gcc-2.95.X .

Положение начало меняться в версиях gcc , начиная с 3.4.0. И ныне генерируемый ими Си-код, по свидетельствам знатоков, как минимум не хуже прежнего, созданного gcc-2.95.X . А если учесть, что старшие версии 3-й ветки позволяет еще и оптимизацию под современные процессоры (коих во времена 2-й ветки и в проекте не было), такие, как Pentium 4 и Athlon (в том числе отдельно — под Northwood, Prescott, Athlon XP и Athlon 64), то подвариант сборки DragonFly gcc3 начинает выглядеть предпочтительней и практически.

Наконец, четвертый вариант дистрибутива — в сборке от GoBSD — сайта компании, специально созданной для дистрибуции этой ОС и поддержки ее пользователей (и вообще формирования сообщества). Этот вариант носит имя GoBSD Distributions Preview и основан на одном из оригинальных стабильных снапшотов проекта, но несколько отличается комплектацией. В частности, он содержит тарбалл дерева pkgsrc , заимствованный из проекта NetBSD, и пакет bootstrap-pkgsrc , адаптирующий эту систему пакетного менеджмента для использования в DragonFly.

Надо заметить, что в текущей версии сборки от GoBSD (т.н. GoBSD Preview 2) были отмечены некоторые мелкие, но неприятные особенности, как-то: ошибки инсталлятора при разбиении диска, при некоторых условиях — некорректное завершение работы установленной системы, и так далее. Так что предпочтение все-таки следует отдать снапшотам с зеркал проекта DragonFly.

При этом мой личный опыт свидетельствует, что для установки на «боевую» рабочую машину, и тем более на «боевой» сервер (а DragonFly уже вполне пригодна и этом качестве, хотя этот вопрос я далее затрагивать не буду) нужно проявить здоровый консерватизм и выбирать последние стабильные снапшоты (файлы их образов маркированы как LATEST-STABLE ), собранные с gcc-2.95.X . Тогда как для целей экспериментальных подойдет, скорее, текущий снапшот LATEST-GCC3 . Подвариант же LATEST-GCC2 кажется наименее востребованным.

Впрочем, версиями «собирающего» компилятора при выборе нужного снапшота можно особенно и не заморачиваться: чем бы он ни был собран, в установленном виде доступными будут оба gcc . И хотя по умолчанию в качестве «рабочей» версии по умолчанию всегда выступает gcc2 , это положение легко изменить (как — будет рассказано в следующей заметке цикла, когда нам это на самом деле понадобится). Так что всегда можно пересобрать систему тем или иным компилятором — по потребности.

Все описанные варианты дистрибутива доступны в Сети в виде iso-образов, сжатых утилитой bzip2 или, реже, gzip . Так что по получении такого файла его следует развернуть (посредством bunzip2 или gunzip , соответственно), «сболванить» любым доступным способом — и можно приступать к установке. Но сначала —

Подготовительные мероприятия

Прежде всего желательно сверить свои возможности, то есть наличное «железо», с потребностями новой ОС. Запросы DragonFly к оборудованию — примерно те же, что и у FreeBSD, как и совместимость с оным — повторюсь, что если отличия и есть, то в лучшую сторону. То есть все более-менее стандартное «железо» поддерживается, устройства, ориентированные на применение исключительно в Windows (win-модемы и win-принтеры) — не поддерживаются, со всякого рода экзотикой — как повезет. Однако с устройствами, критичными именно для установки — дисковыми контроллерами, видеокартами и т.д., — проблем быть не должно. Подробный список заведомо поддерживаемого оборудования можно найти на одной из страниц DragonFlyBSD Wiki — Supported Hardware

Интересно, что в DragonFly уже на стадии установки поддерживаются любые USB-накопители и ряд «чуждых» файловых систем (включая все варианты FAT и ext2/ext3. То есть если заранее озаботиться этой задачей и разместить нужное на флэшку или мобильный винчестер, то можно в ходе инсталляции читать, например, документацию, в том числе и русскоязычную. А можно даже записывать свои впечатления о ходе установки.

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

Программа установки DragonFlyBSD (BSD Installer) в современном ее виде допускает инсталляцию этой системы либо на диск целиком, либо на существующий раздел (слайс, в BSD-терминологии), имеющий идентификатор типа файловой системы 165 в десятичном исчислении (приписанный операционной системе FreeBSD). Конечно, при наличии неразбитого дискового пространства и минимум одной свободной позиции в MBR под первичный раздел (или просто существующего раздела, которым вы готовы пожертвовать на благо DragonFly) это можно обойти — и в следующей части этой статьи я расскажу, как. Однако пользователям, не имевшим ранее дела с программой fdisk от BSD-систем, лучше озаботиться созданием такого раздела заранее. Что легко сделать из Linux — если такового не установлено, то просто загрузившись с любого дистрибутива LiveCD, вызвать fdisk , создать его средствами первичный раздел и присвоить ему нужный идентификатор (в шестнадцатеричном виде, привычном пользователями Linux, он будет равен A5).

Выше я говорил о необходимости минимум одной свободной (или освобождаемой при жертвоприношении раздела) записи в MBR под первичный раздел. Это — почти обязательное требование. Теоретически, начиная со снапшотов конца 2004 г., DragonFly можно поставить и с логический раздел Extended Partition. Однако это уж точно придется делать вручную — BSD Installer такового просто не увидит.

И еще очень важно знать, какие именно первичные разделы (в том числе и объявленные как расширенные и содержащие логические тома) на диске задействованы под файловые системы Windows или Linux, иначе их очень легко будет уничтожить при разметке слайса для DragonFly.

Сколько места выделить под новую ОС — зависит опять-таки от возможностей и потребностей. Сама по себе базовая система DragonFlyBSD очень компактна, и занимает немного больше 200 Мбайт. Однако в это число не входят ни исходники системы, ни дополнительное программное обеспечение, устанавливаемое из пакетов или собираемое из портов, ни, тем более, исходники для работы последней. И потому минимальный рекомендуемый объем дискового пространства в документации определяется примерно в 6 Гбайт. А для того, чтобы в полной мере оценить прелести системы портов или pkgsrc , этих гигабайт желательно иметь по крайней мере 10. И это — не считая пользовательских данных — сколько места отвести под них, вы знаете лучше меня.

И, наконец, последнее: перед загрузкой с инсталляционного диска установите в BIOS своей машины время по Гринвичу (GMT или UTC). Даже при отсутствии постоянного подключения к Сети это даст некоторые дополнительные удобства. Ну а при наличии — вы получите в свое распоряжение личную службу точного времени.

Терминологические замечания

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

Дисковые накопители с ATA-интерфейсом (точнее, конечно, не накопители, а файлы соответствующих устройств, но для нас это сейчас не важно) в DragonFly (как и во FreeBSD) именуются так (табл. 1).

Таблица 1. Номенклатура дисковых накопителей

ad0 Мастер на 1-м канале
ad1 Слейв на 1-м канале
ad2 Мастер на 2-м канале
ad3 Слейв на 2-м канале

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

Как известно, диск может быть разбит на 4 первичных раздела. В BSD-терминологии они обычно именуются слайсами (slices), хотя в DragonFly этот термин не проводится последовательно, тем не менее, имена соответствующих устройств будут такими (табл. 2).

Таблица 2. Номенклатура первичных разделов (слайсов)

ad0s1 1-й слайс
ad0s2 2-й слайс
ad0s3 3-й слайс
ad0s4 4-й слайс

Обращаем внимание — слайсы, в отличие от дисков, нумеруются, начиная с единицы. Нумерация слайсов определяется не порядком их создания, а номером записи в таблице разделов MBR: то есть на диске может существовать только единственный слайс ad0s4 (другое дело — зачем это нужно), прочие теоретически возможные слайсы при этом будут помечены как UNUSED (неиспользуемые).

Наконец, внутри слайса создаются разделы под собственно файловые системы BSD (partitions в терминологии FreeBSD), или подразделы (subpartitions), как они называются в DragonFly: это — некие аналоги логических разделов в Windows и Linux. В отличие от FreeBSD, в DragonFly слайс может содержать до 16 подразделов, имена соответствующих им файлов устройств маркируются литерами латинского алфавита — ad0s1a и так далее. Назначение первых трех подразделов жестко фиксировано: они предназначены для корневой файловой системы, раздела подкачки и описания слайса целиком, прочие же могут использоваться под отдельные ветви файловой системы, типа /usr , /var и так далее (табл. 3)

Таблица 3. Номенклатура подразделов (subpartitions) слайса

ad0s1a / — корень файловой системы
ad0s1b раздел подкачки (swap)
ad0s1c запись таблицы, зарезервированная за описание слайса целиком
ad0s1d
.
ad0s1k
подразделы для отдельных ветвей файлового древа

Слайс может быть размечен как единственный подраздел — именно так происходит при автоматической разметке соответствующей утилитой disklabel ; впрочем, в ходе инсталляции пользователю, скорее всего, дела с ней иметь не придется. В этом случае к нему нужно обращаться так: ad0s1c (вот зачем нужна зарезервированная запись в таблице разделов). А может и не содержать подразделов вообще — и тогда его именем будет просто ad0s1 . Именно таким образом могут выглядеть в ОС BSD-семейства разделы, несущие чуждые ей файловые системы (от Windows или Linux).

На иллюстрациях к последующим разделам статьи можно будет увидеть дисковое устройство с именем da0 . В принципе, имена типа da# соответствуют винчестерам со SCSI-интерфейсом. Таковых в обычной пользовательской машине, скорее всего, нет. Однако накопители с любым интерфейсом, кроме ATA, также предстают перед системой в качестве винчестером SCSI, в том числе и столь распространенные ныне флэшки, карты памяти цифровых камер, внешние диски, подключенные к USB или FireWire (почему так — тайна сия велика есть). Так вот, для подготовки рисунков, иллюстрирующих процесс дисковой разметки, я манипулировал с самой обычной флэшкой — не на рабочем диске же было это делать? Хотя в принципе скриншоты консоли в DragonFly можно было бы сделать даже во время первичной инсталляции — и со временем я надеюсь показать, как (хотя, наверное, и не в этой статье).

И последнее, имеющее отношение к терминологии. Пользователь Linux уже давно привык к разнообразию файловых систем, поддерживаемых этой операционкой в качестве «родных» (native). Однако в DragonFly в роли нативной выступает одна-единственная файловая система — UFS, принятая также во FreeBSD (Unix File System, хотя под этим именем известны и файловые системы иных операционок, отличные по устройству от данной). Теоретически с конца 2004 года поддерживается и ее усовершенствованный, 64-разрядный, вариант — UFS2 («умолчальная» файловая система FreeBSD 5-й ветки), однако практически ею можно воспользоваться только при ручной установке — BSD Installer еще ничего не знает о ее существовании.

Варианты установки

Установочный диск DragonFly — загрузочный, несет на себе инсталлятор собственной конструкции. Кроме того, он являет собой полноценный LiveCD, что допускает выполнение всех необходимых действий, предваряющих установку. Однако начну по порядку.

На первой стадии загрузки появляется обычное для FreeBSD меню выбора режимов загрузки — «умолчального», с отключенным ACPI, в однопользовательском режиме, и так далее. Отличие только в логотипе — стрекоза вместо демона с вилами. Никаких проблем с загрузкой на подручных конфигурациях (весьма, нужно сказать, разнообразных) не возникает. В отличие, опять же, от FreeBSD, которая в «умолчальном» режиме категорически отказывалась грузиться на моей Toshiba, а при отключении ACPI грузилась через раз.

В ходе загрузки файловая система установочного CD монтируется как корневая в оперативной памяти. Для всякого рода установочных действий в ней предназначается каталог /mount .

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

Аккаунт root предназначен для ручной установки системы. После его регистрации появляется приглашение командной строки (полноценный tcsh ), из которой и выполняются все необходимые действия, как то:

  1. создание первичного дискового раздела для установки DragonFly (слайса, в терминологии FreeBSD) с помощью команды fdisk ;
  2. разбиение слайса на разделы под отдельные файловые системы DragonFly (корневую, для каталогов /tmp , /var , /usr и так далее, по потребности), а также выделение пространства под своппинг: все это делается посредством команды disklabel ;
  3. создание собственно файловых систем с помощью команды newfs ;
  4. создание в каталоге /mount подкаталогов — точек монтирования для новообразованных файловых систем;
  5. собственно монтирование их командой mount куда следует — будущего корня в /mount , грядущих /tmp , /var , /usr — в /mount/tmp , /mount/var , /mount/usr , соответственно, и так далее;
  6. перенос содержимого необходимых каталогов с установочного CD на подготовленные файловые системы винчестера — / в /mount , /var в /mount/var , и так далее; делается это не простым копированием, а специально для этого предназначенной утилитой cpdup ;
  7. постинсталляционные действия — установка требуемых прав доступа для некоторых каталогов, удаление ненужных более временных файлов, редактирование необходимых конфигурационных файлов (например, /mount/etc/fstab , /mount/etc/rc.conf , и так далее).

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

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

И еще: дистрибутивный диск DragonFly являет собой настоящий LiveCD, и с помощью root-режима после установки системы можно выполнять всякого рода аварийно-спасательные работы, а также некоторые мероприятия по настройке уже установленной системы.

Второй вариант авторизации — под аккаунтом installer . Это автоматически вызывает штатный установщик DragonFly — BSD Installer, служащий также для начального конфигурирования системы. Именно он и будет предметом дальнейшего рассмотрения.

BSD Installer: установка

Как уже говорилось в предыдущей заметке, BSD Installer — программа, созданная в рамках самостоятельного проекта , и предназначенная для установки любых BSD-систем. Однако пока она оказалась востребованной именно для установки DragonFly (и еще — в LiveCD системе, FreeSBIE, где позволяет превратить ее в полноценную FreeBSD 5-й ветки). Однако именно в DragonFly эта программа показывает себя во всей красе.

В дистрибутиве DragonFly применяется BSD Installer с псевдографическим фронт-эндом, основанным на библиотеке ncurces . Он несколько напоминает по стилю традиционную sysinstall из FreeBSD, но производит впечатление более логичного и понятного, хотя и уступает (пока?) тому в функциональности. Тем не менее, как и sysinstall , BSD Installer — позволяет не только инсталлировать базовую систему, но и выполнить основные ее настройки, Причем не только во время первичной установки, но и, с некоторыми оговорками, и впоследствии.

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

Для начала, сразу после регистрации с аккаунтом installer , установщик предлагает следующие варианты выбора (рис. 1):

  1. установка;
  2. конфигурирование ранее установленной системы;
  3. утилиты LiveCD;
  4. выход в среду LiveCD;
  5. перезагрузка.

Рис. 1. Начальное меню BSD Installer

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

А пока обратимся к первому пункту — установке системы, следующим шагом подтвердим свой выбор — и попадаем в меню выбора диска (рис. 2).

Рис. 2. Меню выбора диска

Поскольку мы предположили, что таковой имеется в единственном экземпляре, выбирать особенно не из чего. А вот дальше предлагается создать на диске раздел под DragonFly, и здесь выбор уже есть: использовать под установку DragonFly диск целиком (entire disk) или его часть рис. 3). Так как мы не собираемся отказываться от ранее установленной системы, первый вариант нас, скорее всего, не устраивает — хотя при нем все происходит очень просто (почему я говорил о желательности отдельного диска для DragonFlyBSD. Да и второй тоже походит не во всех случаях: штатными средствами можно создать слайс только на все оставшееся неразбитым пространство.

Рис. 3. Выбор типа разбиения диска

Если, однако, мы готовы отдать все остатки диска на растерзание DragonFly, все просто: соглашаемся со вторым вариантом, и, после подтверждения уверенности в своей правоте (рис. 4), получаем BSD-слайс соответствующего размера.

Рис. 4. Запрос на подтверждение правильности выбора раздела

Перед положительным ответом на вопрос с рис. 4 неплохо еще раз подумать: все содержимое раздела, если оно имелось, будет потеряно (произойдет не просто изменение типа раздела, но и «обнуление» его начального сектора командой

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

Если же часть неразбитого пространства требуется сохранить таковым для последующего использования в каких-либо целях (и если имеется резерв записей под первичные разделы), придется действовать иначе. Благо, оказывается, что установочный LiveCD нашей системы сохраняет свои «живительные» свойства и после запуска инсталлятора. Предоставляя в расположение пользователя шесть свободных виртуальных консолей из восьми возможных (на второй запущен установщик, на первую выводятся его сообщения). И можно, перейдя в любую из них, авторизоваться там как root (по прежнему без пароля), создать нужный раздел вручную — с помощью программы fdisk . Правда, в BSD-системах этот инструмент не являет собой верх удобства, требуя (даже в интерактивном режиме) явного задания начала и конца раздела в физических (по 512 байт) блоках. И, соответственно, некоторых вычислений.

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

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

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

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

Первым из них будет запрос на ввод, второй- это ручное создание слайсов (при существующей уже разметке сначала будет вопрошаемо, а хотим ли мы этого — с отрицательным ответом по умолчанию). Для этого сначала запрашивается идентификатор типа файловой системы (по умолчанию стоит ID существующего раздела или 0 — для неразмеченного пространства). Тут следует руками указать его десятичное значение (165 — идентификатор FreeBSD/DragonFly). Затем запрашивается стартовый сектор — очевидно, первый сектор этого раздела, — и размер размер раздела в блоках по 512 байт — его следует вычислить посредством bc .

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

Подтвердив свои действия положительным ответом на вопрос

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

Золотые правила трейдинга:  Быстрые линии тренда

При положительном ответе на него все сделанные изменения вступят в силу (и на ранее размеченном диске при ошибке можно будет распроститься с его содержимым). Так что следует предварительно просмотреть все ранее введенное — благо, это легко сделать пролистыванием буфера истории виртуальной консоли, перейдя в режим его просмотра, нажав клавишу ScrollLock (а сам просмотр выполняется как клавишами PageUp/PageDown — поэкранно, так и стрелками Up и Down — построчно). И при обнаружении ошибки отказаться от изменений и запустить команду fdisk по новой. Впрочем, из нее можно в любой момент выйти без последствий и стандартным образом — комбинацией клавиш Control>+C.

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

Порядок создания дисковых разделов средствами fdisk подробно описан на ее man-странице — благо она во время инсталляции доступна с LiveCD. А вообще-то, как я уже говорил, если поступиться принципами, проще всего создать слайс (и тем более слайсы) для DragonFly заблаговременно — средствами любого наличного LiveCD с Linux. А при наличии установленной FreeBSD это легко сделать средствами ее sysinstall .

По завершении ручной разметки слайса (или слайсов) нужно сделать его доступным для BSD Installer’а. Для чего придется вернуться в его начальное меню, выбрать в нем пункт Exit to LiveCD (см. рис. 1) и авторизоваться как installer заново.

Тем или иным способом создав первичный раздел, выбираем его в соответствующем меню для разбиения на подразделы (subpartitions). Вариант, предлагаемый по умолчанию, таков (рис. 5):

Рис. 5. Создание дисковых подразделов, нормальный режим

Эта схема вполне разумна, и для пользователя, ранее с BSD системами дела не имевшего, может быть принята. Если он, тем более, собирается пользовать DragonFly сугубо для экспериментальных целей. Разве что при недостатке места уменьшить раздел под /usr (вплоть до минимума в 4096 Мбайт — почему я и говорил ранее, что инсталляция DragonFly требует около 6 Гбайт дискового пространства) и swap (при памяти от 512 Мбайт он практически не задействуется).

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

Пока же только замечу, что кроме нормального режима разметки подразделов, проиллюстрированного на рис. 5, существует еще и т.н. «режим эксперта» (рис. 6). В котором, помимо указания размера разделов, для отдельных из них можно еще и включить или выключить режим Softupdates, а также определить индивидуально размер блока и фрагмента файловой системы. Процедура создания последней (то есть исполнение команды newfs или, в терминах DOS/Windows, форматирование) совмещена в меню BSD Installer с разметкой разделов и осуществляется в один прием с ней — по выбору Accept and Create, вызывающим последнее предупреждение, с которым «пользователь соглашается и форматирование совершается».

Рис. 6. Создание дисковых подразделов, режим эксперта

По окончании создания файловой системы (а для больших разделов он может затянуться) задается вопрос — приступить ли к переносу файлов базовой системы. В отличие от большинства дистрибутивов Linux (а также FreeBSD и прочих BSD-систем), при этом не происходит никакой распаковки архивов или развертывания пакетов. Просто файловая система LiveCD (находящаяся в этот момент, напомню, в оперативной памяти) со всем ее содержимым — каталогами, подкаталогами и отдельными файлами) копируется на соответствующие разделы ранее созданного слайса, подмонтированные в виртуальный каталог /mnt : корень — в корень, /usr — в /usr , и так далее. Правда, не обычной командой cp , а специально для того предназначенной утилитой cpdup , обеспечивающей полную идентичность файловой структуры источника и приемника (включая воспроизведение жестких и символических ссылок, файлов устройств, атрибутов доступа и принадлежности). Это важно помнить при аварийно-спасательных работах, о чем будет подробнее говориться в следующей статье.

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

Под занавес начальной установки — предложение установить загрузчик, точно такой же loader , что и во FreeBSD. И установить его можно опять же в загрузочный сектор диска или слайса. В первом варианте — прописывание BSD’шного loader’а в MBR диска — он позволяет осуществить мультисистемную загрузку с любого первичного раздела (на котором собственные средства загрузки имеются, конечно). Второй же вариант потребует обеспечения загрузки DragonFly средствами Lilo или GRUB, что сделать не сложнее, чем для FreeBSD, но к теме нашего сегодняшнего разговора отношения не имеет. Тем более, что BSD Loader, не смотря на свою внешнюю простоту и непрезентабельность, успешно справляется с загрузкой своей родной операционки (еще бы!), а также Windows, Linux и любой другой BSD. При условии, что их собственные загрузчики лежат в загрузочных секторах первичных дисковых разделов — но и об этом разговор еще впереди.

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

Интермедия: стратегия дисковой разметки

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

Итак — сакраментальный российский вопрос — что делать? (при разметке диска), и кто виноват? (если «опять все не получилось!» — как сказал в отчаянии хирург, кромсая большим медицинским скальпелем внутренности пациента после неудачной операции аппендикса).

Правда, на второй вопрос ответить легко: виноват, в 99 случаев из ста, сам хирург, то есть пользователь, устанавливающий систему. А вот первый — это действительно вопрос, сродни Гамлетовскому.

Существует широко известный стандарт FHS (Filesystem Hierarchy Standart), описание которого доступно в русском переводе благодаря Виктору Костромину. Хотя его конкретная реализация и не столь уж общепризнанна, как это кажется его авторам (или, скорее, как бы им хотелось), положенные в его основу принципы вполне можно взять на вооружение при определении стратегии дисковой разметки.

В основу FHS положена пара альтернатив:

  1. противопоставление неизменяемых и изменяемых файловых систем;
  2. обособление файловых систем неразделяемых и разделяемых.

Контент неизменяемых файловых систем создается при инсталляции ОС ее первичной настройке, и в дальнейшем не претерпевает модификации. По крайней мере, без участия администратора — а тот должен прибегать к ней лишь при наличии веских причин. Типичный пример — корневая файловая система. Такая ее ветвь, как /usr , также по хорошему должна бы быть неизменяемой, и, как мы увидим дальше, в BSD, в отличие от Linux, это легко реализовать.

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

К изменяемым ветвям файлового древа можно отнести также каталоги /usr/local и, в ряде случаев, /usr/X11R6 . Конечно, инсталляция дополнительного программного обеспечения (для которого и предназначен /usr/local ) — обычно привилегия администратора (и это подчеркивается атрибутами доступа к этим каталогам). Однако у пользователя, ведущего активную софтверную жизнь (а таких среди истинных POSIX’ивистов — большинство) это происходит достаточно часто. Что же касается /usr/X11R6 — то теоретически, по стандарту FHS, он предназначен только для штатных компонентов оконной системы X — все X-приложения должны помещаться в каталоги /usr , /usr/local или /opt (в зависимости от используемой системы пакетного менеджмента). Однако последний в BSD-системах не используется вообще), а X-приложения, например, устанавливаемые из системы портов и коллекции пакетов FreeBSD (используемых также в DragonFly) распределяются между ветвями /usr/X11R6 и /usr/local весьма причудливым образом. В альтернативной же системе пакетного менеджмента — pkgcrs , заимствованной из NetBSD, — в число изменяемых попадают также каталоги /usr/pkgsrc (собственно дерево управления этой системой) и /usr/pkg , куда помещаются собранные бинарники, в том числе и Иксы — в подкаталог /usr/pkg/xorg (каталог /usr/X11R6 при этом не используется).

Я подробно остановился на альтернативе неизменяемости/изменяемости потому, что она важна для пользователя вообще и, как станет ясным в дальнейшем, для пользователя DragonFly в особенности. Что же касается неразделяемости/разделяемости (то есть доступа к каталогам только с локальной машины или также и с удаленных), то эта альтернатива имеет значение в основном для администратора сети, и пользователю десктопа мало интересна. Поэтому замечу только, что к неразделяемым ветвям файловой иерархии относится корень локального файлового древа, тогда как такие ветви, как /usr , /usr/X11R6 , /usr/local и аналогичные — должны быть разделяемыми, для обеспечения запуска приложений с удаленных машин.

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

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

  1. легко восстановимые с дистрибутива — корневая файловая система и каталог /usr — только туда помещаются компоненты базовой системы (то, что во FreeBSD называется Distributions);
  2. восстановимые с затратами времени — каталоги для дополнительных программ, не входящих в базовый комплект — /usr/local , /usr/X11R6 или /usr/pkg (в зависимости от используемой системы пакетного менеджмента);
  3. восстановимые с затратами времени и трафика — /usr/src (исходники базовой системы), /usr/ports или /usr/pkgsrc (собственно древа систем управления пакетами), а также ветви последних — /usr/ports/distfiles или /usr/pkgsrc/distfiles (исходники программ для сборки их из портов); их специфика — в том, что они а) регулярно обновляются (например, через cvs), то есть в принципе невосстановимы с дистрибутива (а в дистрибутива DragonFly их просто нет) и б) содержат личные данные (файлы конфигурации ядра, собственноручно модифицированные Make-файлы и тому подобное);
  4. практически невосстановимые пользовательские данные (каталог /home со всеми его ответвлениями).

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

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

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

То есть каталог / — первый кандидат на обособление в отдельном разделе слайса. И остаться в нем должны только ядро ( /kernel ) и такие ветви, как /boot , /etc , /dev , /modules , /root, /bin, /sbin — то, без чего запуск и функционирование системы окажутся невозможными.

Маленькое отступление: Внимательный читатель (и к тому же пользователь Linux по натуре) наверняка задаст вопрос: пардон, а где же здесь общесистемные библиотеки? В частности, glibc , без которой ничего не работает. Ибо в Linux предназначенный для них каталог находится непосредственно в корне файловой системы ( /lib ), которого в списке кандидатов на исконность корней не видно. Забегая впред, отвечу: файлы главной системной библиотеки в BSD-системах (здесь она величается просто — libc ) размещаются в каталоге /usr/lib , который мы в следующем абзаце отчленим от корня и поместим на отдельный раздел.

Но как же тогда будут работать бинарники из каталогов /bin и /sbin в однопользовательском режиме, когда никакие другие файловые системы, кроме корневой, не монтируются? — задаст следующий вопрос пользователь, просветленный Linux’ом. Очень просто: в DragonFly все системные утилиты из каталогов /bin и /sbin (а их содержимое — и есть системные утилиты, просто в первом лежат те, к которым иногда прибегает и простой пользователь, а утилиты из второго ему без надобности), слинкованы с libc статически, и в наличии ее не нуждаются.

Реплика в сторону: раньше (включая все версии 4-й ветки) так было и во FreeBSD, но в 5-й ветке бинарник из каталогов /bin и /sbin линкуются динамически, а статически слинкованные утилиты «на всякий пожарный случай» располагаются в каталоге /restore .

Так что от выноса на отдельный раздел неизменяемого (и легко восстановимого) каталога /usr — вреда ни малейшего. А заодно отделяем и изменяемые каталоги — /tmp и /var , ну и конечно же /home . То есть пока мы движемся в русле схемы разметки, предложенной по умолчанию. Но вот теперь пойдут разночтения. Потому что /usr в этом случае оказывается сборной солянкой неизменяемых и изменямых подкаталогов, к тому же — разной степени восстановимости. Так что с безжалостностью эсторского палача-расчленителя по прозвищу Голый Дьявол приступим к его разделу.

Для начала вычленяем из древа /usr его заведомо изменяемую часть — каталог /usr/obj : это то место, куда по умолчанию помещаются промежуточные продукты компиляции ядра и базовой системы, как будет показано в следующей статье, роль его весьма велика.

Теперь — умеренно восстановимые части, /usr/local и /usr/X11R6 , а при использовании системы pkgsrc — также и /usr/pkg . Это обеспечит нам сохранность инсталляций дополнительных программ при переустановке базовой системы.

Правда, не до конца: для обеспечения контроля их зависимостей потребуется еще и сохранить базу данных установленных пакетов. Так что «умолчальный» ее каталог /var/db/pkg также логично было бы вынести на отдельный раздел. Хотя, если это делать не хочется (а так оно и есть — больно уж много чести для массива данных в десяток мегабайт, эту сохранность можно обеспечить иными способами (о них речь пойдет в статье про управление пакетами), не говоря уже о простом backup.

Теперь отрезаем изменяемые и трудновосстановимые части — /usr/ports и (или) /usr/pkgsrc . Лишним резоном к чему будет специфика из содержимого — очень большое число (многие десятки тысяч) очень маленьких (по несколько байт) файлов. И потому из состава этих ветвей целесообразно вытащить их менее специфичные и наиболее «затратные» (в том числе и финансово:-) компоненты — /usr/ports/disfiles (или, соответственно, /usr/pkgsrc/distfiles ). На чем сердце расчленителя может успокоиться — вряд ли на индивидуальной машине имеет смысл дробить на подкаталоги /home или /var (хотя на большом сервере это, скорее всего, необходимость).

В итоге получаем максимальное целесообразное количество отдельных ветвей файловой системы — 14, что вполне укладывается в допустимый максимум слайса DragonFly (16 подразделов). Впрочем, очевидно, что все перечисленное и не понадобится: вряд ли есть смысл в использовании и системы портов, и pkgsrc . Так что реальное число ветвей сразу уменьшается на три. Ну и без отдельного раздела под /usr/X11R6 также можно обойтись в любом случае. При pkgsrc он вообще не нужен, а при использовании портов его можно оставить внутри /usr : если следить за тем, чтобы все X-приложения собирались в каталог /usr/local (как — будет рассказано в статье про управление пакетами), то /usr/X11R6 сразу станет фактически неизменяемым.

Далее, может иметь смысл помещение трудновосстановимых и невосстановимых разделов ( /usr/src , /usr/ports , /usr/ports/distfiles , /home ) на отдельный слайс: именно поэтому ранее я столь подробно останавливался на том, как средствами DragonFly сделать это вручную. Смысл такого действия — облегчить полную переустановку системы в случае необходимости. Правда, надеюсь, таковой не будет — в следующей статье будет говориться и о том, как избирательно восстановить с дистрибутива только нужные ветви файлового древа. Но — береженого Бог бережет.

Итак, с количеством и назначением разделов разобрались. Теперь остается только «разделить по Божьи» между ними наличное дисковое пространство. И действительно — «тут очень рассчет нужон». Причем при рассчетах следует помнить о специфике файловой системы UFS вообще: в ней быстродействие файловых операций (и так не рекордное сравнительно с Ext2fs или ReiserFS) резко падает, как только объем свободного места становится менее 10%. Так что, как говорится, запас горба не сломит (тем более на современных-то дисках).

Для начала — вычисляем корень. Тут можно спокойно согласиться с «умолчальным» предложением в 256 Мбайт. Да и того за глаза хватит — у меня, например, в данный момент в корне (того самого размера) задействовано даже менее 50 Мбайт; ну да ладно — не будем жмотничать на важнейшем каталоге.

С предлагаемым по умолчанию объемом раздела под каталог /var я, не мудрствуя лукаво, тоже согласился (правда, у меня он обычно используется едва на 15-15%). А вот от раздела под /tmp я давно отказался: при достаточном количестве памяти (начиная с 512 Мбайт — точно, а меньше — я и забыл, когда было) в этот каталог целесообразно смонтировать файловую систему в оперативной памяти (mfs — Memory Filesystem), и при финальных настройках системы (в заключительно разделе этой статьи) мы будем исходить из этого.

Остается отпрепарировать каталог /usr . Ясно, что при предложенной выше схеме разметки 8 «умолчальных» (и даже 4 допускаемых) гигабайта для него — излишне. Подсчет объема, занимаемого «родными» подкаталогами (от /usr/bin до /usr/share ) в установленной системе даст около 180 Мбайт, «чистые» Иксы добавят еще сотню. То есть при использовании портов на весь /usr можно кинуть 512 Мбайт, а при pkgsrc — сократить этот объем вдвое.

Объем промежуточных продуктов компиляции базовой системы, включая ядро, помещаемых в каталог /usr/obj , составляет, в зависимости от настроек ее условий, 500-600 Мбайт. С учетом разрастания ее в будущем — отводим под это дело 1 Гбайт. Причем при тех же 512 Мбайт ОЗУ и в этот каталог можно смонтировать файловую систему mfs, что имеет как свои плюсы, так и минусы, которые подробно будут рассмотрены в следующей статье.

Труднее всего определиться с каталогом /usr/local (или его аналогом /usr/pkg для системы pkgsrc ). Требуемое под него место определяется исключительно аппетитами пользователя на дополнительный софт. У меня под /usr/local отведено 2 Гбайт — и до их исчерпания (при установленных KDE и OpenOffice) еще далеко.

Теперь исходники базовой системы. Вместе с ядром в распакованном из тарбалла (доступного на некоторых ftp-зеркалах проекта) виде они занимают около 400 Мбайт. Снапшот текущего дерева, полученный через cvs, будет несколько больше. Так что под каталог /usr/src я не поскупился бы гигабайтом — с запасом на будущее.

Как ни странно, трудно определиться также с пространством под /usr/ports (или /usr/pkgsrc ). Правда, объем дерева соответствующей системы вычисляется легко — в распакованном из тарбалла виде они займут около 150 Мбайт. Однако следует учесть, что по умолчанию здесь же окажутся и промежуточные продукты сборки — распакованные исходники, объектные модули и т.д., а для pkgsrc — еще и собранные бинарные пакеты. От всего этого потом можно избавиться — однако, дабы не получить в процесс сборки KDE или OpenOffice сообщения об исчерпании дискового пространства, лучше создать под эти каталоги разделы с о-очень большим запасом. Руководство к системе pkgsrc рекомендует 5 Гбайт, однако для /usr/ports , мне кажется, хватит и двух.

Относительно /usr/ports/distfiles (или /usr/pkgsrc/distfiles ) можно сказать то же самое, что и о /usr/local (или /usr/pkg ): выделяемое под них пространство определяется запросами пользователя. Руководство по pkgsrc определяет полный объем исходников для этой системы в 10 Гбайт. Какой процент из входящих в pkgsrc 5 тысяч приложений потребуется именно вам — предлагается рассчитать в качестве домашнего задания. Я лично под /usr/ports/distfiles ограничиваюсь 2 Гбайт.

И, наконец, с /home все ясно. Под него отводится места а) сколько нужно, б) сколько можно или в) сколько не жалко. У меня это всегда — все оставшееся дисковое пространство (собственно, так BSD Installer и предлагает по умолчанию.

В заключение — о swap-разделе, не несущем файловой системы. Рекомендуемый его объем равен удвоенному ОЗУ, и я всегда следую этому правилу. Конечно, при объеме памяти 512 Мбайт и больше можно вообще обойтись без подкачки (или ограничиться swap-файлом, на всякий случай). Однако мы ведь решили разместить на mfs (то есть в оперативной памяти) каталог /tmp , а возможно, и /usr/obj , под что физической памяти, при некоторых услвоиях, может и не хватить. И тут в дело вступит swap — ведь для системы он вместе с физическим ОЗУ предстает в виде единой виртуальной памяти.

Казалось бы, с точки зрения быстродействия, замена дискового раздела разделом подкачки — все равно что сменить шило на мыло. Однако на самом деле это не так, и механизм виртуальной памяти DragonFly обеспечит некоторый прирост производительности и в этом случае. А кроме того, перемещение этих ветвей файлового древа в mfs обеспечивает автоматическую очистку от временных файлов при рестарте системы. Что однозначно полезно для /tmp (хотя в некоторых случаях может быть лишним для /usr/obj — но это мы обсудим в следующей статье.

Свои представления об оптимальной схеме дисковой разметки для установки DragonFly я суммировал бы так (табл. 4).

Таблица 4. Схема дисковой разметки для DragonFly

## Раздел Mnt Размер Назначение
1 ad0s1a / 256 Мбайт Файлы и каталоги, необходимые для старта в однопользовательском режиме
2 ad0s1b swap 1024 Мбайт Раздел подкачки
2 mfs /tmp Нет Временные файлы
3 ad0s1d /var 256 Мбайт Изменяемые файлы кэшей спуллингов и т.д.
4 ad0s1e /usr 512 Мбайт Основная часть базовой системы
5 ad0s1f /usr/obj 1024 Мбайт Временные продукты компиляции базовой системы
6 ad0s1g /usr/local 2048 Мбайт Пользовательские программы из портов и пакетов
7 ad0s1h /usr/ports 2048 Мбайт Дерево системы портов
8 ad0s1n /usr/ports/disfiles 2048 Мбайт Исходники для сборки портов
9 ad0s1p /home Все, что осталось Пользовательские данные

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

Столь дробная схема разметки полезна еще и тем, что позволяет индивидуально определить размер блока и его фрагмента для каждой файловой системы — в зависимости от специфики размещаемых на ней данных. При разметке в нормальном режиме (см. рис. 5) оба эти параметра, влияющие на производительность файловых операций, эффективность использования дискового пространства и максимально возможное количество файлов, вычисляются автоматически — исходя из объема раздела. И в большинстве случаев с этим можно согласиться. Исключение — файловая система ветви /usr/ports (или /usr/pkgsrc ), Как уже говорилось, обе они образованы невообразимым количеством малюсеньких файлов. И потому для них, не зависимо от объема раздела, размеры блока и фрагмента лучше сделать поменьше — например, 1024 b 512 байт соответственно.

Золотые правила трейдинга:  Брокеры бинарных опционов с демо-счетом без депозита

И еще, как можно видеть из рис. 6, режим эксперта позволяет включить или выключить механизм Softupadets (по умолчанию включено для всех файловых систем, кроме корневой). Это такая интересная штука, которая волшебным образом способствует как росту быстродействия файловых операций, так и повышению надежности файловой системы. Однако она имеет альтенартиву — чисто асинхронное монтирование, при котором производительность растет еще больше, хотя и надежность резко уменьшается. Почему оно обычно и не рекомендуется к употреблению резонными людьми. Однако при вычленении из файловой иерархии частей, в надежности заведомо не нуждающихся (в нашем случае это будут /tmp и /usr/obj ), к ним вполне может быть применимо — с предварительным отключением Softupadets в режиме эксперта).

О монтировании файловых систем речь пойдет в заключительной части статьи. А более полную информацию о затронутых здесь вопросах устройства файловой системы UFS вообще поищите в материалах списка ссылок.

BSD Installer: конфигурирование

Возвращаемся к нашему основному сюжету — установке DragonFly. Как уже было сказано, следующий шаг в этом направлении — начальное конфигурирование. Конечно, его можно выполнить и в дальнейшем — либо загрузившись с того же LiveCD и выбрав в меню установщика соответствующий пункт, либо — запустив BSD Installer из уже установленной системы. Однако первое — это лишние телодвижение, а второе «из коробки» можно выполнить только после установки с диска от GoBSD. В системе, установленной со снапшотов проекта DragonFly, потребуются не вполне тривиальные действия по настройке самого installer’а:-). Так что не вижу причин, почему бы благородному дону не выполнить все возможные настройки сразу по завершении базовой установки.

Меню начального конфигурирования (рис. 7) позволяет выполнить следующее:

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

Рис. 7. BSD Installer: главное меню конфигурирования

Большинство этих действий сводятся к ответам на вполне тривиальные вопросы — остановлюсь только на наиболее важных и интересных моментах.

При определении часового пояса (Select timezone) перво-наперво спаршивается, установлены ли «железные» часы на время по Гринчиу (UTC). И если вы последовали моему совету из вводной части, и сделали это перед инсталляцией — соглашайтесь, не пожалеете. Ну а потом остается только выбрать континент и город на нем, например, Europe -> Moscow, или Asia -> Kamchatka (это, оказывается, город такой:-)).

Процедура коррекции даты и времени очевидна, с паролем root’а также проблем нет — в DragonFly на него не накладывается никаких ограничений по минимальной длине или максимальной простоте. А вот от создания пользовательского аккаунта (Add a user) на данном этапе я бы воздержался. Как известно, наиболее простой способ локализации во FreeBSD — это задание специального атрибута пользователя, именуемого class (в нашем случае его значением будет, например, russian . И DragonFly унаследовала это понятие. Но вот задать класс пользователя на стадии установки не получится (такое поле просто не предусмотрено). Так что лучше заняться этим делом потом — с помощью одной из специальных утилит управления учетными записями ( adduser или pw ).

Тем не менее, если есть желание создать пользовательский аккаунт, сделать это просто: нужно только заполнить соответствующие поля (рис. 8). Нужно только иметь ввиду несколько моментов. В качестве пользовательской оболочки (login shell) по умолчанию предлагается /bin/tcsh — опять-таки соглашайтесь, альтернативой на данном этапе может быть только весьма убогая (с точки зрения интерактивности) /bin/sh . И еще — не забыть в поле Other Group Memebership вписать группу wheel — без этого новому пользователю не получить прав администратора командой su . Не повредит и членство в группе operator — оно позволит от лица обычного пользователя выполнять некоторые обыденные действия, обычно доступные только root’у (например, завершить работу системы).

Рис. 8. Создание пользовательского аккаунта

Как это в обычае для систем BSD-клана, настройка сети в DragonFly (пункт Configure network interface) выполняется не просто, а предельно просто — проще даже (если такое возможно), чем у ее матушки FreeBSD.

Для начала предлагается список настраиваемых сетевых интерфейсов (рис. 9). Первым в нем стоит тот, который соответствует наличной сетевой карте — он, собственно, и подлежит сейчас настройке. В моем случае (чипсетная сеть от ICH4) имя его fxp0, другие сетевые устройства будут иметь иное название. Например, сетевые карты неизвестного генезиса обычно определяются как ne0. При сомнении можно перейти в другую виртуальную консоль (опять вспомним, что пред нами — LiveCD) и уточнить имя требуемого интерфейса командой ifconfig .

Рис. 9. Настройка сетевых интерфейсов

Так что выбираем первый пункт списка и жмем Enter. Нас запрашивают — использовать ли DHCP-сервер или настроить сетевые параметры вручную. Если дело происходит в локальной сети предприятия, использующей DHCP (а в большинстве случаев так оно и есть), или в сети нормального «домашнего» провайдера — выбор первого очевиден (кстати, он и отмечен по умолчанию). Система автоматически отыскивает машину, выполняющую функции DHCP-сервера нашей сети, и через некоторое время выдает сетевые параметры, включая динамически присвоенный нашему хосту IP-адрес в виде, подобном такому: inet 19X.XXX.X.XXX). На чем процедура настройки первого сетевого интерфейса и заканчивается — можно выходить из данного подменю и посмотреть на прочие. Каковыми будут:

  • lp0 — соединение по параллельному порту;
  • lo0 — имитация сетевого соединения внутри локальной машины (т.н. loopback-интерфейс);
  • ppp0 — обычное модемное соединение через последовательный порт по одноименному протоколу (Point-to Point);
  • sl0 — также последовательное соединение, но по протоколу SLIP;
  • fait0 — интерфейс между сетями с IP-протоколами версий 6 и 4.

Интерфейсы lp0 и sl0 ныне практического значения, скорее всего, не имеют, IPv6 мало кем еще поддерживается, а ppp0 — это отдельная тема, которую я затрагивать не буду. Что же касается loopback-интерфейса, то он в принципе весьма важен — например, для запуска web-сервера на локальной машине. Однако именно он корректно настроен по умолчанию — это легко проверяется командой

в ответ на что последует серия сообщений вида

Так что можно спокойно переходить к пункту Configure hostname and domain. Действия в котором сводятся к тому, чтобы вписать в соответствующие поля имя своей машины (произвольное или по согласованию с админом — например, mydragonfle ) и домена (типа mydomain.ru . Это — в сети предприятия (да и то не всегда). В сети «домашнего» провайдера никакого имени хоста и домена не потребуется.

Настройка консоли позволяет установить раскладки клавиатуры (Set keyboard map, рис. 10), экранные шрифты (Set console font, рис. 11) и, при необходимости, карты соответствия (Set screen map, рис. 12). То есть — выполнить, например, полную русификацию системы. Причем — в любых вариантах: и в традиционном для Unix’ов сочетании KOI-ввода и CP866-вывода (с требуемой картой соответствия), и просто установив шрифты и раскладки для KOI8-R (необходимость в карте соответствия при этом отпадает). Имеются в комплекте даже шрифты и раскладки для чуждой нам кодировки CP1251.

Рис. 10. Установка консольного шрифта для вывода

Шрифты, содержащих символы кириллицы, в комплекте представлены для кодировок: cp866, koi8-r и koi8-u, cp1251 и iso5 (кодировка для Sparc’ов). Для каждой кодировки имеются вариатны с матрицами от 8×8 до 8×16, а для кодировок cp866 и koi8-r имеется еще и три гарнитуры (если так можно выразиться). Что выбрать — дело вкуса и потребностей. Я последнее время остановился на шрифте koi8-r-8×16 . Тем более, что, как будет показано в следующей статье, загрузка шрифта при старте — мера временная.

Рис. 11. Установка расклаки клавиатуры

Русских раскладок клавиатуры — также несколько, для кодировкок cp866 и iso5, а также две для koi8-r: весьма странная ru.koi8-r и привычная по старым (до-Windows’ным) временам ru.koi8-r.shift. Тем не менее, нынче ни с одной из этих раскладок работать неудобно, потому в дальнейшем их придется менять.

Рис. 12. Установка карты соответствия кодировок ввода и вывода

Установка карты соответствия рнужна только при различии кодировок для клавиатурного ввода и экранного вывода. Поскольку первая будет скорее всего koi8-r, а вторая может оказаться cp866, то именно koi-r2cp866 и нужно ставить. Тем более, что другой-то и нет: если вам позарез требуется cp1251 для ввода, то нужно ставить или экранный шрифт для нее же (благо, он есть, но вид программ с псевдографикой будет безобразным), либо искать карту соответствия (или сделать ее самому). Очевидно, что при сипользовании «сквозной» koi8-r карта соответствия также не понадобится.

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

И еще, забегая вперед, отмечу, что DragonFly содержит полный набор русских локалей, в том числе даже ru_RU.UTF-8. А вот чего в ней не обнаружилось — так это команды locale — список их приходится смотреть визуально — в каталоге /usr/share/locale .

И, наконец, дополнительные пакеты (Install extra software packages). Список их не велик — cdrtoosl , cvsup (собранный без поддержки GUI) и еще пара-тройка, имеющих отношение к BSD Installer и его front-end’у (рис. 13). Хотя эти пакеты как бы входят в базовую систему, устанавливаются они в подкаталоги ветви /usr/local и фиксируются в базе данных, расположенной в /var/db/pkg .

Рис. 13. Установка дополнительных пакетов

Следует заметить, что запрос на установку дполнительных пакетов следует только при инсталляции со снапшотов проекта. При использовании сборки GoBSD — допллнительные пакеты установятся сами по себе — хотя и в урезанном составе (без cdrtoosl и cvsup ). Но зато, как я уже упоминал, BSD Installer будет сразу готов к работе.

Теперь, казалось бы можно и перезагрузится, не правда ли? Можно. Но есть еще одна возможность — воспользоваться «живительными» свойствами установочного диска и довести настройки до логического конца, уже вручную.

Дополнительные настройки

Вообще-то тема настройки DragonFly — совершенно особая, и со временем ей будет посвящена специальная статья. Здесь же я просто дам несколько рецептов, направленных на получение, после перезагрузки, базовой системы, готовой к употреблению на все 100% — по выходе из BSD Installer степень готовности можно определить в 99%.

Чтобы перейти к ручным настройкам, нужно вернуться в начальное меню BSD Installer и выбрать в нем пункт Exit to Live CD (см. рис. 1), или просто авторизоваться как root на любой свободной виртуальной консоли. В результате чего в нашем распоряжении оказываются два важнейших инструмента конфигурирования — командная оболочка (полноценный tcsh ) и текстовый редактор ( ee — не богатый возможностями, но для наших целей достаточный и простой в использовании).

Теперьт определяемся с объектами конфигурирования. В первую очередь нам нужно а) довести до ума русификацию, б) обеспечить монтирование всех необходимых файловых систем, и в) создать комфортные условия для работы в консоли. Все три цели достигаются редактированием трех файлов — /etc/ttys , /etc/fstab и /etc/rc.conf .

Редактирование /etc/ttys понадобится для ликвидации упомянутого выше безобразия с внешностью псевдографических программ. Для чего в строках, описывающих виртуальные консоли и имеющих вид вроде достаточно заменить тип терминала по умолчанию ( cons25 ) на cons25r .

Файл /etc/fstab формируется автоматически при создании разделов и файловых систем на них. Однако если мы решили монтировать в каталог /tmp и (или) /usr/obj файловую систему mfs (как это было предложено ранее), то об этом нужно позаботиться самостоятельно, дописав в /etc/fstab такие строки:

Обращаем внимание на опции монтирования: async предписывает тот самый асинхронный режим, о котором я упоминал в прошлом разделе, а noatime запрещает обновление времени последнего доступа, что несколько способствует быстродействию. Для каталога /usr/obj добавляется еще и опция noauto — этот каталог нужен только при пересборке ядра и базовой системы, и держать его смонтированным постоянно нет никакого резона.

Файл /etc/rc.conf — главный конфиг для стартовых скриптов при загрузке в BSD-стиле, и со временем мы его изучим во всех деталях. Пака же нам важно включить службу консольной мыши, обеспечить нормальную реакцию клавиатуры и правильный вывод русского текста (последнее — только в случае koi8-r как кодировки экранного вывода.

Мышь с USB-интерфейсом включить проще всего: для этого достаточно отыскать в /etc/rc.conf строку

и заменить умолчальное значение на YES .

Мышь с разъемом PS/2 (или, скажем, ноутбучный тачпад — интерфейс у него, скорее всего, тот же) потребует уже нескольких строк:

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

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

Наконец, последнее действие. Если у вас есть под рукой русский текст на носителе, который можно смонтировать в DragonFly (если нет — прошу поверить на слово), и вы после русификации консоли в «сквозной» кодировке koi8-r попробуете его посмотреть, то будете весьма удручены: некоторые русские буквы исчезнут с экрана (слаба Богу, что не из файла:-) при первом же движении курсора мыши. В причины этого пока вдаваться не будем, а скорее исправим это безобразие строкой

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

Да, чуть не забыл — еще хорошо бы создать обычный пользовательский аккаунт — это легко сделать утилитой adduser в интерактивном режиме, ответив на несколько вполне очевидных вопросов. Не забыв только, что на вопрос о классе пользователя нужно отвечать russian — это автоматически установит одноименную локаль (точнее — локаль ru_RU.KOI8-R ). Если же аккаунт был создан посредством BSD Installer, то этот класс требуется для него определить, что проще всего сделать так:

Вот теперь действительно все. Можно перезагружаться и смотреть, что же мы получили в итоге.

Впечатления

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

Умолчальное ядро DragonFly (т.н. GENERIC ) собрано с модульной поддержкой максимально широкого круга оборудования. Во всяком случае, почти все наличествующее у меня «железо» никаких проблем не вызвало: вполне справно функционировали «из коробки» и тачпад моего ноутбука в параллели с USB-мышью, и чипсетный звук от Intel (ICH4) вкупе с чипсетной же сетевушкой, и USB-накопители (флэш-драйвы и мобильный винчестер Fujitsu Handy Drive).

Правда, в DragonFly не используется файловая система устройств (devfs) — файлы устройств именуются статически. С чем связаны некоторые, вполне понятные, неудобства при монтировании USB-накопителей: в зависимости от очередности их втыкания они оказываются то устройством /dev/da0 , то — /dev/da1 , и так далее, однако с этим легко примириться. Тем более, что, по информации с сайта проекта, в дальнейшем в DragonFly планируется поддержка демона devd — некоего аналога механизма udev в Linux.

Что меня весьма порадовало — в DragonFly по умолчанию включена поддержка Линуксовой файловой системы ext2fs — во FreeBSD для этого требуется перекомпиляция ядра. Проблем с монтированием журналируемого ее варианта ext3fs) также не возникает (правда, естественно, без журналирования). И еще одна приятная мелочь: ext2fs при перезагрузке или останове системы (командами reboot и halt , соответственно) размонтируется корректно, с установкой clean byte. Это заслуживает похвалы, так как во FreeBSD по сию пору раздел ext2fs, не размонтированный перед рестартом руками, бита чистого размонтирования не получает, и повторное его монтирование, без проверки утилитой fsck (разумеется, Linux’овой же, установленной из портов, ни в коем случае не от FreeBSD), оказывается невозможным.

Конечно, для полного счастья в DragonFly не хватает очень многих приложений. И возникает вопрос, откуда их брать. Частичный ответ на это был дан в первой заметке: из прекомпилированных пакетов на соответствующих сайтах, портов FreeBSD, pkgsrc проекта NetBSD и, в некотором количестве, из собственного дерева dfports . Да и ручную сборку пока никто не отменил. Ну а подробнее мы поговорим на эту тему, когда речь дойдет до пакетного менеджмента.

Ссылки

DragonFly BSD Handbook.
Главный источник сведений об установке.

A Quick Start on DragonFly
Быстрое вхождение в тему (для опытных и нетерпеливых).

Алексей Федорчук — DragonFly: Установка и первичная настройка Версия для печати

Энциклопедия маркетинга

Каталог консалтинговых компаний

Библиотека маркетолога

Почему удобно использовать социальные сети в различных целях

Дженнифер Аакер, Энди Смит Глава из книги «Эффект стрекозы: Все об улетных промо-кампаниях в социальных сетях»
Издательство «Альпина Бизнес Букс/Unitedpress»

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

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

Самир посетил одну из лучших больниц Мумбаи и проконсультировался с врачом. Анализы показали, что число красных кровяных телец у него гораздо ниже нормы; кроме того, в его крови были обнаружены бластные клетки. Врач посоветовал ему как можно скорее уехать из страны и обратиться к врачам на родине. Вернувшись в США, не успев даже добраться до родного Сиэтла, Самир попал в госпиталь Университета Роберта Вуда Джонсона в Нью-Джерси. Там у него диагностировали острый миелобластный лейкоз — рак, начинающийся в клетках костного мозга, при котором в крови больного быстро растет число белых кровяных телец, мешающих производству нормальных клеток крови. Острый миелобластный лейкоз — одна из самых распространенных среди взрослых форм лейкемии и к тому же одна из самых агрессивных. Так перед Самиром встала самая большая проблема всей его жизни. В 2008 году, как и сейчас, большинство больных лейкемией умирали. Однако Самир был полон решимости победить болезнь. После нескольких месяцев химиотерапии и иных форм консервативного лечения врачи объявили Самиру, что его единственный шанс — пересадка костного мозга, для которой требуется донор с теми же лейкоцитарными антигенами костного мозга, что и у больного.

Поскольку типы тканей определяются наследственностью, 25—30% больных в состоянии найти подходящего донора среди родственников. Остальные 70% вынуждены обращаться к услугам национальной программы донорства костного мозга — федеральной базы данных, где зарегистрировано более 8 миллионов потенциальных доноров. Чаще всего подходящий донор находится среди представителей той же этнической группы, к которой принадлежит пациент. Для Самира этот сценарий не подходил. От отца он унаследовал крайне редкий генетический тип, для которого было чрезвычайно трудно найти соответствие. Его брат, родители, двоюродные братья и сестры прошли тестирование, однако никто из них не оказался подходящим донором. Кроме того, выяснилось, что лишь 1,4% доноров, зарегистрированных в национальной программе, были родом из Южной Азии. Таким образом, шанс Самира найти подходящего донора оценивался как один к двадцати тысячам. (У белых европеоидов шансы оцениваются как один к пятнадцати). Увы, мест, где можно было искать донора, оказалось крайне немного. Казалось бы, можно было попробовать начать поиски в Индии, откуда была родом семья Самира, ведь Индия — вторая по населенности страна в мире, где проживает около 1 миллиарда 200 миллионов человек. Однако в Индии не существует национальной системы регистрации доноров. Словом, для Самира практически не оставалось шансов.

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

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

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

Пожалуйста, найдите минуту, чтобы прочитать это сообщение. У моего друга, Самира Бхатиа, обнаружен острый миелобластный лейкоз — рак крови. Этот диагноз ему поставили неделю назад, застав нас всех врасплох, ведь Самиру всего 31 год и он всегда был в прекрасной форме.

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

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

Золотые правила трейдинга:  Отзыв о брокере PlusOption – развод и лохотрон Как выводить деньги с Плюс Оптион

Три шага, которые вы можете предпринять

1. Пожалуйста, зарегистрируйтесь в качестве донора.

Процедура регистрации очень проста: она включает лишь мазок со щеки (2 минуты) и заполнение анкеты (3 минуты). Зарегистрироваться очень просто — так же, как и стать донором, если вас выберут. Пожалуйста, посмотрите, где это можно сделать, на //www.helpvinayorg/dp/mdex.php?q=evem.

2. Распространите эту информацию. Пожалуйста, отправьте это письмо, как минимум, 10 людям (особенно южноазиатского происхождения) и попросите их сделать то же самое. Сообщите своим друзьям, где находятся ближайшие пункты регистрации доноров костного мозга, и попросите их зарегистрироваться. Если есть такая возможность, проспонсируйте проведение тестирования у вас в офисе или в местном сообществе. Чтобы помочь Самиру, тестирование должно пройти в ближайшие 2—3 недели. Используйте свои связи, чтобы распространить это послание, — сегодня у нас больше возможностей, чем когда бы то ни было, для того, чтобы привлечь множество людей и стать частью массового интернет-движения за спасение жизней.

3. Узнайте больше. Чтобы узнать больше, зайдите на сайт //www.nickmyers.com/helpsameer. На сайте подробно описано, как организовать тестирование, там же можно узнать больше об остром миелобластном лейкозе и прочесть ответы на часто задаваемые вопросы о регистрации доноров костного мозга. Если вы хотите побольше узнать о том, где требуется помощь, зайдите на //www.helpvinay.org/dp/index.php?q=node/108. А на www.matchpia.org вы увидите историю Пиа Авол — еще один случай успешной борьбы с лейкозом, и тоже — в нашем сообществе.

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

Это письмо Роберт разослал ближайшим друзьям и коллегам Самира — четырем-пяти сотням членов его «экосистемы», включая коллег-бизнесменов, инвесторов, родственников из Южной Азии, и друзьям по работе. Эти люди, в свою очередь, отправили послание своим друзьям, и оно начало распространяться с огромной скоростью. Через 48 часов оно достигло уже 35 тысяч адресатов, и кампания по спасению Самира началась.

Вскоре друзья Самира узнали, что еще одному члену их сообщества недавно был поставлен тот же самый диагноз: это был Винай Чакраварти, 28-летний врач, проживающий в Бостоне. Друзья Самира, энергичная группа спасателей, тут же объединились с командой, занимавшейся спасением Виная. Совместными усилиями они задействовали ресурсы социальных сетей на базе Web 2.0, а также сервисы Facebook, Google Apps и YouTube, призывая людей по всей стране вливаться в ряды доноров костного мозга.

Их цель была ясна, и кампания шла полным ходом. Через несколько недель, в дополнение к существующим пунктам регистрации доноров костного мозга, обе команды организовали тестирование и запись потенциальных доноров более чем в пятнадцати компаниях Западного побережья, включая Cisco, Google, Intel, Oracle, eBay, PayPal, Yahoo! и Genentech. Волонтеры на Восточном побережье взяли на вооружение разработанные командой документы и сопутствующие материалы. Через 11 недель напряженной работы было проведено 480 организованных тестирований и в национальной базе зарегистрировано 24 611 новых доноров. Команда привлекла 3500 волонтеров, добилась более чем миллиона упоминаний в СМИ и привлекла на свои веб-сайты 150 тысяч посетителей. «Это самая масштабная кампания, в которой нам довелось участвовать, — заявила Эйжа Блум из Азиатско-американской донорской программы. — Другим пациентам удавалось привлекать где-то по тысяче доноров. Мы и представить не могли, что кампания разрастется до таких масштабов». В самом деле, никто не мог вообразить, что она изменит весь механизм проведения тестирования и регистрации потенциальных доноров костного мозга.

Однако, наверное, самым значимым результатом кампании стали два найденных донора: для Виная и для Самира. В августе 2007 года, лишь через несколько месяцев после начала кампании, для Виная нашелся подходящий донор, а две недели спустя Самира известили о том, что и для него найден идеально подходящий донор — 10 баллов из 10. С учетом времени, когда доноры были зарегистрированы в базе данных, можно считать, что их появление стало прямым результатом кампании. При этом всем было ясно, что традиционным путем ни для Самира, ни для Виная доноров найти было невозможно. Обычно проходило от четырех до шести недель до того момента, как новый донор появлялся в национальной базе, так что обоим требовалось куда более 20 тысяч новых доноров, чтобы получить статистически значимый шанс на отыскание подходящего кандидата за столь короткое время. Как писал Самир в своем блоге, «найти нужного донора за остававшееся у меня время было почти невозможно. Однако вокруг нас объединились сотни рук и сердец. Все вы подарили мне новую жизнь, и у меня нет нужных слов, чтобы отблагодарить вас за это».

Как написать письмо, которое побудит людей к действиям и станет двигателем перемен

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

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

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

«Эффект стрекозы» в действии

Как команде Самира удалось достигнуть, говоря словами Роберта Чатвани, «чего-то по-настоящему грандиозного»? Они и не собирались создавать модель для дальнейшего использования — эффективного и без излишних затрат. Они лишь хотели спасти жизнь своего друга. Однако, достигнув гораздо большего и сумев зарегистрировать в национальной базе данных 24 611 выходцев из Южной Азии — потенциальных доноров костного мозга, Роберт и его друзья обнаружили способ, позволяющий достигнуть практически любой цели. Его эффективность обеспечивают четыре принципа — фокусирование, привлечение внимания, вовлечение и действие. Для простоты можете запомнить это как формулу «фокус + 3В».

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

Чтобы понять, почему команда Самира оказалась столь эффективной, рассмотрим, как она применяла все четыре принципа: фокус, привлечение внимания, вовлечение и воплощение. Прежде всего, эта команда продемонстрировала отличные способности к фокусированию, сосредоточившись на одной-единственной цели. Это было нетрудно, ведь вердикт врачей был совершенно недвусмысленным. Шансы найти подходящего донора костного мозга равнялись одному к двадцати тысячам. Команде нужно было за несколько недель привлечь к участию в национальной программе донорства как минимум 20 тысяч выходцев из Южной Азии.

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

«Стрекозиная» модель

Фокусирование + 3В

«Эффект стрекозы» достигается за счет согласованности четырех крыльев: работая вместе, они способны продемонстрировать впечатляющую эффективность.

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

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

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

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

Затем команда, спасавшая Самира, привлекла внимание аудитории, заставив ее прочувствовать беду своего друга, используя фотографии и личные, вызывавшие сочувствие, послания. Они использовали все типы средств массовой информации — как социальные сети (блоги, видеосервисы, вирусную рассылку, Facebook, мобильные сервисы, листы рассылки), так и традиционные СМИ (PR-средства, телевидение, журналы, телефонный обзвон, постеры, газеты), привлекли к своей работе знаменитостей из самых разных сфер (Барак Обама, бывший в то время сенатором, написал послание в поддержку кампании, поскольку один из друзей Виная попросил его об этом. После этого команда вовлекла в свою работу множество людей, сделав историю Самира популярной, рассказывая о его беде с искренней, вызывающей сопереживание интонацией, используя для этого видеосервисы и блоги, — так что через некоторое время эту историю приняли близко к сердцу даже те, кто не знал Самира лично. Команда использовала целевые послания для земляков Самира из Южной Азии; в рассылках для иных типов аудитории большее внимание уделялось его молодости, недавней женитьбе или профессиональным достижениям в качестве бизнесмена, работающего в сфере высоких технологий.

Команда, занимавшаяся спасением Самира, создала собственный интернет-сайт //www.helpsameer.org/strategy/, куда стекались истории, новости, информация, отклики. Отсюда волонтеры могли получить все необходимые данные — флаеры, литературу, информацию о том, как создать видеоролик. На сайте была даже выложена подробная методичка «Как организовать тестирование потенциальных доноров на рабочем месте» — документ с несложной инструкцией и шаблонами необходимых писем, которые были полезны каждому, кто хотел провести подобную процедуру. Там же можно было найти ссылки на обращения родных Самира в формате pdf, ссылку на страницу Виная, образцы писем, которые читатели могли отправить своим друзьям, шаблоны обращений, которые можно было вставить в стандартную подпись к электронным письмам, баннеры для сайтов и блогов, видеоролики для вставки на личные страницы в Facebook. Команда Виная вместе с командой Самира работала над тем, чтобы как можно активнее использовать все эти ресурсы. Постоянная связь между двумя командами в конечном итоге помогла им организовать совместную масштабную кампанию.

И наконец, команда Самира пробудила в людях желание помочь, предлагая им понятные и легкие в использовании инструкции и призывы к действию в каждом своем материале. К примеру, на интернет-сайте таких призывов было множество. В специальном интерактивном календаре были обозначены даты и места проведения тестирований для регистрации в качестве доноров костного мозга, а главная страница встречала посетителей вопросом: «Привет, ты уже зарегистрировался?» Кроме того, здесь же содержалась пошаговая инструкция по организации тестирования, а для потенциальных доноров — подробный рассказ о том, что их ожидает во время процедуры. Чтобы подкрепить свои призывы, команда Самира постоянно отслеживала результаты кампании и сообщала их всем задействованным в кампании участникам, друзьям, родным и просто незнакомым посетителям сайта.

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

Используем возможности блогов

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

Пусть тот, кому вы хотите помочь, пишет. Успех блога зависит от личности автора и предоставляемой им информации. Самир оказался страстным, увлеченным и крайне плодовитым блоггером. «Сначала Самира пришлось убеждать завести блог, но, как только он начал писать, о его истории узнало огромное число людей. Они получили возможность услышать голос Самира, и это очень помогло нашей кампании, — рассказывал Роберт. — Это стало для нее мощным толчком». Если вы пытаетесь помочь не одному-единственному человеку или ваш подопечный не в состоянии писать, — станьте его голосом, его связующим звеном с миром Интернета: ведите блог, как можно чаще используя местоимение «я».

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

«Несите мою историю в мир, говорите о моих проблемах и советуйте, что мне делать дальше», — говорил он своим друзьям.

Используйте блог, чтобы побуждать людей к немедленному действию. Самир в своем блоге писал: «Из тех представителей Южной Азии, что зарегистрировались в качестве доноров, лишь 30—40% объявляются, будучи выбранными в качестве доноров. Думаю, каждый из вас, на минуту представив себе эту цифру, может понять, сколь это ужасно. В этом случае наши враги — отчасти страх, отчасти невежество, а отчасти — остатки древнего инстинкта выживания, свойственного нам, индийцам: чаще всего мы готовы помочь лишь самым близким для нас людям».

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

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

Трансплантация костного мозга Самиру была проведена осенью 2007 года. За день до операции он писал в блоге с обычным оптимизмом, чувством юмора и эмоциональным подъемом: «Думаю, что я везунчик. У меня достаточно энергии, я не ощущаю ни боли, ни дискомфорта. Пока я тут наслаждаюсь больничной едой, перезваниваю друзьям и пытаюсь работать. Да, кстати, вам наверняка интересно, почему раковые больные вечно лысые? Это для того, чтобы увеличить Зону для Поцелуев (З/П). Неужели вам это раньше не приходило в голову? :)» Кроме того, Самир разместил на YouTube фото и видеозапись процедуры трансплантации костного мозга — небольшие эпизоды, начиная с клипа, где он с волнением смотрит на сумку с контейнером для костного мозга и крутит ее, пытаясь отыскать табличку со своим именем. Отец Самира просит не крутить контейнер слишком активно, на что тот смеется: «Не крутить слишком сильно? Эти клетки пролетели через всю страну и даже пробрались через зону выдачи багажа!» В следующей части Самир держит контейнер и смотрит, как клетки костного мозга вводят в его тело.

Через три месяца после трансплантации, за несколько дней до Рождества 2007 года, у Самира случился рецидив. В своей обычной манере он пишет в блоге 26 декабря: «Я не верю в повторение пройденного. Полученный опыт помогает нам расти, и неважно, какую боль — физическую или эмоциональную — он несет с собой. В конце концов, что такое наша жизнь, если не постоянный рост?»

После нескольких рецидивов и месяцев отважной борьбы с болезнью, в марте 2008 года Самир умер. Безутешные друзья и родные заказали заупокойную службу, организовав ее трансляцию в Интернете. Через Сеть в ней участвовали более пятисот человек со всего мира. Некоторые из них знали Самира лично, другие нет — но каждый из них был искренне тронут его историей. Запись этой службы позднее была выложена на Google Video. За семь недель ее посмотрели более 7 тысяч человек. Слайдшоу, составленное из фотографий Самира, рассказывающее о его преданности своей культуре, родным и друзьям (а также любви к нарядам, включая клетчатые юбки), просмотрели более 6 тысяч человек. «Мы знали, что тысячи друзей Самира по всему миру не смогут лично отдать ему последний долг, поэтому мы выложили материалы в Сеть, — говорит Роберт. — Мысль о том, что мы можем перешагнуть через барьеры и границы, поддерживала нас. Таким образом мы дали друзьям и родным Самира почувствовать свою связь со всем миром, — связь, которая стала венцом его жизни».

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

Однако это не конец истории. Созданное друзьями Самира и Виная движение и его наследие продолжали расти по всему миру. С помощью своей новаторской стратегии, включавшей использование современных технологий, своей преданности и настойчивости, команды, помогавшие Самиру и Винаю, совместными усилиями добились регистрации в национальной базе доноров костного мозга более 20 тысяч выходцев из Южной Азии, найдя доноров обоим пациентам. Своими попытками увеличить число доноров они вдохновили многих на помощь другим и спасли множество жизней. Среди 7500 человек, зарегистрировавшихся в качестве доноров в районе Сан-Франциско, в течение года были подобраны доноры для 80 больных лейкемией. А в 2008 году, благодаря усилиям двух команд, было подобрано 266 подходящих доноров, каждый из которых поделился своим костным мозгом с кем-то из больных.

Кампания, проведенная друзьями Самира и Виная, практически удвоила число выходцев из Южной Азии, зарегистрированных в качестве доноров костного мозга. По данным Эйжи Блум из Азиатско-американской программы донорства, число тех, кто соглашается стать донором, будучи выбранным системой, увеличилось до 50%. Более того, кампания помогла многим людям избавиться от своих предубеждений, касающихся благотворительности, что спасло много жизней. Так, студентка Рина Мета, учившаяся на фармацевта, узнала о деятельности команд по спасению Самира и Виная от своего приятеля, приславшего ей приглашение поучаствовать в тестировании, проходившем во Фремонте, штат Калифорния. «Зарегистрироваться в качестве донора оказалось так просто, что я тут же решила сделать это и предложила всем друзьям и близким, включая родителей, сделать то же», — рассказывает Рина. Через шесть месяцев дома у Рины раздался телефонный звонок: сотрудники донорской программы предложили ей пройти дополнительные тесты, поскольку она могла оказаться подходящим донором для одного из пациентов. В итоге Рина стала донором вспомогательных стволовых клеток для 18-летнего юноши, больного лейкемией. «Я решила, что непременно стану донором, поскольку все мои страхи и возможные неудобства бледнели перед тем, через что ему приходилось пройти», — рассказала она.

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

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

Как совершить нечто грандиозное и заставить мир вращаться

От Роберта Чатвани

Надежные брокеры с русским языком:

1. Сформулируйте для себя одну-единственную цель и сфокусируйтесь на ней.

2. Расскажите историю.

3. Действуйте, затем анализируйте.

4. Ищите сотрудничества.

5. Доверяйте работу другим.

6. Измеряйте результаты.

7. Действуйте, ошибайтесь, снова действуйте, добивайтесь успеха.

Астрономы обнаружили галактику, состоящую из темной материи

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

Новая галактика

Эта необычная галактика называется Dragonfly 44. Ученые обнаружили ее в 2020 году, но до недавнего времени практически никаких данных о составе, массе и других физических характеристиках галактики ничего не было известно.

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

Dragonfly 44 расположена на расстоянии в 300 миллионов световых лет от Земли и является частью галактического скопления Кома. По массе галактика совпадает с нашей – примерно триллион солнечных масс. Однако, несмотря на значительный размер, Dragonfly 44 очень тусклая. Она излучает лишь сотую часть того света, который исходит от Млечного пути. Это заставило астрономов предположить, что в составе новой галактики больше темной материи, чем традиционных звезд и газа.

Уникальный состав

Галактики с подобным составом – не новость для научного сообщества, но обычно они гораздо меньше по размеру, чем Dragonfly 44. В этой редкой астрономической находке расположено меньше миллиарда звезд, которые собраны в несколько кластеров. По словам ученых, такое незначительное количество звездных кластеров разорвалось бы на мелкие части, если бы их не удерживало гравитационное поле.

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

Сегодня ученые говорят о том, что из скрытой материи (темная материя и энергия) состоит больше 90% Вселенной. Получается, что большая часть космоса не поддается изучению и даже наблюдению. Существование галактик и звездных кластеров, подобных Dragonfly 44, – пока единственное прямое доказательство существования темной материи.

Бонусы за открытие торгового счета забирать тут:
Понравилась статья? Поделиться с друзьями:
Народный рейтинг лучших бинарных брокеров
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: