diff --git a/ru_RU.KOI8-R/articles/euro/article.sgml b/ru_RU.KOI8-R/articles/euro/article.sgml index f59bad7a22..d7bfb1afa5 100644 --- a/ru_RU.KOI8-R/articles/euro/article.sgml +++ b/ru_RU.KOI8-R/articles/euro/article.sgml @@ -1,366 +1,367 @@ - %articles.ent; ]>
Символ евро во <systemitem class="osname">FreeBSD</systemitem> Aaron Kaplan
aaron@lo-res.org
2002 2003 The FreeBSD Documentation Project $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.general; В этом документе будет сделана попытка помочь вам начать работу с - новым символом Euro на вашей новой клавиатуре, которую - вы купили в начале 2002 года для перехода на новую общую валюту. - Сначала мы сконцентрируемся на более важных вопросах, таких, как - правильное отображение символа на консоли. Последующие разделы - посвящены настройке конкретных программ типа + новым символом Euro на вашей новой клавиатуре, которую + вы купили в начале 2002 года для перехода на новую общую валюту. + Сначала мы сконцентрируемся на более важных вопросах, таких, как + правильное отображение символа на консоли. Последующие разделы + посвящены настройке конкретных программ типа X11. Много полезной информации было получено от Oliver Fromme, Tom - Rhodes и многих других. Спасибо! Без вас этой статьи бы не - было! + Rhodes и многих других. Спасибо! Без вас этой статьи бы не + было! Об Евро вкратце Если вы уже чувствуете себя уверенно при работе с локализацией, как она описана во Руководстве по FreeBSD, то вас могут заинтересовать только - следующие факты, которые помогут вам быстро вникнуть в суть: + следующие факты, которые помогут вам быстро вникнуть в суть: ISO8859-15 - + Это несколько модифицированная версия широко используемого - набора символов ISO8859-1. В него включен символ Евро. - Используется для задания переменных окружения LANG и - LC_CTYPE. + набора символов ISO8859-1. В него включен символ Евро. + Используется для задания переменных окружения LANG и + LC_CTYPE. iso15-8x16.fnt Шрифт &man.vidcontrol.1; для консоли /usr/share/syscons/keymaps/*.iso.kbd Клавиатурные раскладки, соответствующие вашему языку. Укажите одну из них в качестве значения для параметра - keymap из файла - rc.conf. + keymap из файла + rc.conf. LC_CTYPE Используется для указания правильного типа символов при вашей - локализации. + локализации. XkbLayout "lang(euro)" Параметр настройки XFree86. /usr/X11R6/lib/X11/fonts/*/fonts.alias Обязательно приведите ваши шрифты для X11 к виду -*-..-*-iso8859-15 - + Общее замечание - + В последующих разделах мы будем часто обращаться к термину ISO8859-15. Это стандартное обозначение начиная с FreeBSD 4.5. В более старых версиях стандартным обозначением было ISO_8859-15 или DIS_8859-15. Если вы используете более старую версию FreeBSD, обязательно посмотрите в каталоге /usr/share/locale/, какое используется соглашение по наименованию. - + Консоль - + Настройка шрифта для консоли В зависимости от разрешения вашей консоли и её размера вам нужно - задать одну из таких строк в rc.conf: + задать одну из таких строк в rc.conf: - font8x16="iso15-8x16.fnt" # из /usr/share/syscons/fonts/* -font8x14="iso15-8x14.fnt" + font8x16="iso15-8x16.fnt" # из /usr/share/syscons/fonts/* +font8x14="iso15-8x14.fnt" font8x8="iso15-8x8.fnt" Это приведёт к выбору шрифта ISO8859-15, известному также как - Latin-9. ISO8859-15 является вариантом ISO8859-1. Вы можете увидеть - разницу между ними, посмотрев на символ Евро: его десятичное значение - равно 164. В ISO8859-1 вы увидите кружок с четырьмя полосками по - углам. Часто он называется универсальным символом валюты. В - ISO8859-15 место маленького кружка занимает символ Евро. Если его нет, - то шрифты более или менее идентичны. + Latin-9. ISO8859-15 является вариантом ISO8859-1. Вы можете увидеть + разницу между ними, посмотрев на символ Евро: его десятичное значение + равно 164. В ISO8859-1 вы увидите кружок с четырьмя полосками по + углам. Часто он называется универсальным символом валюты. В + ISO8859-15 место маленького кружка занимает символ Евро. Если его нет, + то шрифты более или менее идентичны. На момент написания этого документа единственным пригодным к - использованию шрифтом был iso15-8x16.fnt. Другие - выдавали ISO8859-1, хотя название говорило о другом. + использованию шрифтом был iso15-8x16.fnt. Другие + выдавали ISO8859-1, хотя название говорило о другом. - После задания этого шрифта сообщения некоторых консольных - приложений будут выглядеть искажёнными. Это происходит в силу того, - что они предполагают использование другого шрифта/набора символов, - такого, как ANSI 850. Одним из примеров может выступать + После задания этого шрифта сообщения некоторых консольных + приложений будут выглядеть искажёнными. Это происходит в силу того, + что они предполагают использование другого шрифта/набора символов, + такого, как ANSI 850. Одним из примеров может выступать sysinstall. Однако в большинстве - случаев это не имеет большого значения и сильно не беспокоит. + случаев это не имеет большого значения и сильно не беспокоит. Следующим шагом вы должны либо перезагрузить вашу систему для того, - чтобы изменения вступили в силу, либо (вручную) выполнить те действия, - которые происходят при начале работы системы: + чтобы изменения вступили в силу, либо (вручную) выполнить те действия, + которые происходят при начале работы системы: &prompt.user; vidcontrol -f iso15-8x16.fnt Для проверки того, был ли выбран шрифт, выполните такой короткий - скрипт на языке awk: + скрипт на языке awk: #!/usr/bin/awk -f BEGIN { for(i=160;i<180;i++) printf"%3d %c\n",i,i } В результате знак Евро должен быть в позиции 164. Настройка вашей клавиатуры на использование Евро Большинство клавиатурных раскладок уже должно быть корректно - настроено. Другими словами: Если у вас немецкая клавиатура и ваши - клавиши с умляутами работают, то вы можете пропустить этот раздел, так - как клавиатура уже отображает какую-то комбинацию клавиш (к - примеру: Alt Gr - e) в символ с десятичным значением 164. - Если вы сталкиваетесь с проблемами, лучше всего проверить в каталоге + настроено. Другими словами: Если у вас немецкая клавиатура и ваши + клавиши с умляутами работают, то вы можете пропустить этот раздел, так + как клавиатура уже отображает какую-то комбинацию клавиш (к + примеру: Alt Gr + e) в символ с десятичным значением 164. + Если вы сталкиваетесь с проблемами, лучше всего проверить в каталоге /usr/share/syscons/keymaps/*.kbd. Формат файлов - раскладок клавиатуры описан в &man.keyboard.4;. Утилита - &man.kbdcontrol.1; может использоваться для загрузки пользовательских - клавиатурных раскладок. + раскладок клавиатуры описан в &man.keyboard.4;. Утилита + &man.kbdcontrol.1; может использоваться для загрузки пользовательских + клавиатурных раскладок. После выбора правильной клавиатурной раскладки она должна быть - указана в файле /etc/rc.conf такой строкой: + указана в файле /etc/rc.conf такой строкой: keymap="german.iso" # or another map Как указано выше, этот шаг, скорее всего, был уже вами выполнен во - время установки (в sysinstall). Если это не - так, либо перезагрузитесь, либо загрузите новую клавиатурную раскладку - посредством &man.kbdcontrol.1;. + время установки (в sysinstall). Если это не + так, либо перезагрузитесь, либо загрузите новую клавиатурную раскладку + посредством &man.kbdcontrol.1;. Для проверки раскладки клавиатуры, переключитесь на другую консоль - и в приглашении на вход в систему вместо имени - входа попробуйте набрать клавишу Euro. - Если она не работает, отправьте сообщение об ошибке через - &man.send-pr.1; либо проверьте, что вы действительно выбрали правильную - раскладку клавиатуры. + и в приглашении на вход в систему вместо имени + входа попробуйте набрать клавишу Euro. + Если она не работает, отправьте сообщение об ошибке через + &man.send-pr.1; либо проверьте, что вы действительно выбрали правильную + раскладку клавиатуры. - На этом этапе клавиша Euro ещё не работает в - bash или - tcsh. + На этом этапе клавиша Euro ещё не работает в + bash или + tcsh. Исправление переменных окружения Командные процессоры (bash, tcsh) обращаются к библиотеке - &man.readline.3;, которая, в свою очередь, использует переменную - окружения LC_CTYPE. LC_CTYPE должна быть - задана до полного запуска оболочки. К счастью, для этого достаточно - добавить строку: + &man.readline.3;, которая, в свою очередь, использует переменную + окружения LC_CTYPE. LC_CTYPE должна быть + задана до полного запуска оболочки. К счастью, для этого достаточно + добавить строку: export LC_CTYPE=de_DE.ISO8859-15 в ваш .bash_profile (bash), или: setenv LC_CTYPE de_DE.ISO8859-15 в ваш файл .login (tcsh). Конечно же, de_DE должно быть заменено на то, что - соответствует вашему языку. Затем завершите работу с системой, войдите - в систему снова и проверьте, что клавиша Евро работает. Теперь - большинство консольных приложений должно воспринимать клавишу Евро. - Однако для специализированных программ, таких, как, например, - pine, могут потребоваться дополнительные - шаги по их настройке. + соответствует вашему языку. Затем завершите работу с системой, войдите + в систему снова и проверьте, что клавиша Евро работает. Теперь + большинство консольных приложений должно воспринимать клавишу Евро. + Однако для специализированных программ, таких, как, например, + pine, могут потребоваться дополнительные + шаги по их настройке. Альтернативой изменению .login и .bash_profile является задание переменных - окружения через механизм &man.login.conf.5;. Этот подход имеет - преимущество в назначении классов входа в систему определенным - пользователям (к примеру, французам, итальянцам, и так далее) - в одном месте. + окружения через механизм &man.login.conf.5;. Этот подход имеет + преимущество в назначении классов входа в систему определенным + пользователям (к примеру, французам, итальянцам, и так далее) + в одном месте. - + Настройка X11 - Измените /etc/XF86Config следующим - образом: + Измените /etc/X11/xorg.conf + (/etc/X11/XF86Config в случае если вы используете + &xfree86;) следующим образом: Option "XkbLayout" "de(euro)" И снова, замените de на то, что соответствует вашему языку. С этого момента клавиатура должна быть настроена правильно. Как и в разделе о консоли, должен быть выбран правильный шрифт. В случае KDE перейдите к KDE control center -> Personalization -> Country & Language -> Charset и смените его на ISO8859-15. Подобные же шаги должны быть выполнены для kmail и других приложений. Другим хорошим способом является изменение ваших файлов fonts.alias. Следует отметить, что шрифт fixed должен быть изменен на правильный набор символов: файл автора /usr/X11R6/lib/X11/fonts/misc/fonts.alias выглядит примерно так: ! $Xorg: fonts.alias,v 1.3 2000/08/21 16:42:31 coskrey Exp $ fixed -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-15 variable -*-helvetica-bold-r-normal-*-*-120-*-*-*-*-iso8859-15 (...) Как и в разделах о консоли, в специализированных приложениях всё ещё могут остаться настроенными шрифты ISO8859-1 в их базах данных &man.xrdb.1;. Одним из видимых примеров является xterm. Как правило, достаточно изменить соответствующий конфигурационный файл из каталога /usr/X11R6/lib/X11/app-defaults, добавив правильный шрифт. Продемонстрируем это на примере xterm. - + &prompt.root; cd /usr/X11R6/lib/X11/app-defaults/ &prompt.root; vi XTerm Добавьте такую строку в начало файла: *font: -misc-fixed-medium-r-normal-*-*-120-*-*-c-*-iso8859-15 И наконец, перезапустите X и проверьте, что шрифты могут выводиться, - выполнив вышеприведённый скрипт на awk. + выполнив вышеприведённый скрипт на awk. Все основные приложения должны воспринять клавиатурную раскладку и настройки шрифта. - + Открытые проблемы - + Конечно, автор будет рад получить отклики. Кроме того, по крайней мере дайте мне знать, если ли у вас решения для следующих открытых проблем: - Описание альтернативного способа настройки XFree86: - x11/xkeycaps + Описание альтернативного способа настройки XFree86: + x11/xkeycaps - Настройки в GNOME + Настройки в GNOME - Настройки в XFCE + Настройки в XFCE - Настройки для (X)Emacs + Настройки для (X)Emacs - Описание UTF-8 + Описание UTF-8 - Описание libiconv как эффективного - способа преобразования между ISO8859-15 и UTF-{8,16} внутри - приложений + Описание libiconv как эффективного + способа преобразования между ISO8859-15 и UTF-{8,16} внутри + приложений
diff --git a/ru_RU.KOI8-R/articles/explaining-bsd/article.sgml b/ru_RU.KOI8-R/articles/explaining-bsd/article.sgml index 6654152938..5d9e211388 100644 --- a/ru_RU.KOI8-R/articles/explaining-bsd/article.sgml +++ b/ru_RU.KOI8-R/articles/explaining-bsd/article.sgml @@ -1,654 +1,654 @@ %articles.ent; ]>
Что такое BSD Greg Lehey -
grog@FreeBSD.org
+
grog@FreeBSD.org
 &tm-attrib.freebsd; &tm-attrib.amd; &tm-attrib.apple; &tm-attrib.linux; &tm-attrib.opengroup; &tm-attrib.sun; &tm-attrib.xfree86; &tm-attrib.general; В мире программ с открытыми исходниками, слово - Linux практически стало синонимом слова - Операционная Система, хотя это далеко не - единственная операционная система &unix;, исходные коды которой - доступны широкой публике. Согласно данным Internet - Operating System Counter, в апреле 1999-го 31,3% всех - подключённых к Internet машин работали под Linux. 14,6% - использовали BSD &unix;. Некоторые из мировых лидеров в области - Web-услуг, например Yahoo!, - работают под BSD. Самый загруженный в мире FTP-сервер 1999 года - (сейчас он не работает), - ftp.cdrom.com, функционировал под управлением BSD и передавал - 1,4 Тбайта данных в день. Очевидно, что это + Linux практически стало синонимом слова + Операционная Система, хотя это далеко не + единственная операционная система &unix;, исходные коды которой + доступны широкой публике. Согласно данным Internet + Operating System Counter, в апреле 1999-го 31,3% всех + подключённых к Internet машин работали под Linux. 14,6% + использовали BSD &unix;. Некоторые из мировых лидеров в области + Web-услуг, например Yahoo!, + работают под BSD. Самый загруженный в мире FTP-сервер 1999 года + (сейчас он не работает), + ftp.cdrom.com, функционировал под управлением BSD и передавал + 1,4 Тбайта данных в день. Очевидно, что это не узкий, специализированный рынок: можно сказать, что BSD — это тщательно скрываемая тайна. Так в чём же секрет? Почему известность BSD оставляет - желать лучшего? Эта публикация ставить целью ответить на эти и - другие вопросы. + желать лучшего? Эта публикация ставить целью ответить на эти и + другие вопросы. На протяжении всего текста обращайте внимание на - выделенные отличия BSD от Linux. + выделенные отличия BSD от Linux. - + Что такое BSD? BSD означает Berkeley Software Distribution. Так называлось программное обеспечение, распространявшееся в исходных кодах Калифорнийским Университетом в Беркли, которое сначала представляло из себя дополнения к операционной системе &unix; компании AT&T. На основе версии 4.4BSD-Lite были созданы несколько операционных систем с открытыми исходными кодами. В их состав включены разработки других проектов, среди которых особо следует выделить Проект GNU. Вот что такое собственно операционная система BSD: - Ядро BSD, отвечающее за планировку процессов, управление - памятью, поддержку многопроцессорных систем (SMP), работу с - устройствами и так далее. + Ядро BSD, отвечающее за планировку процессов, управление + памятью, поддержку многопроцессорных систем (SMP), работу с + устройствами и так далее. - В отличие от Linux, существует несколько - ядер BSD, отличающихся возможностями. + В отличие от Linux, существует несколько + ядер BSD, отличающихся возможностями. - Библиотека C, основной системный интерфейс - программирования. + Библиотека C, основной системный интерфейс + программирования. - Библиотека C в BSD основывается на коде из - Беркли, а не из Проекта GNU. + Библиотека C в BSD основывается на коде из + Беркли, а не из Проекта GNU. - Оболочки, файловые утилиты, компиляторы, редакторы - связей и другие утилиты пользователя. + Оболочки, файловые утилиты, компиляторы, редакторы + связей и другие утилиты пользователя. - Некоторые из них базируются на коде GNU, а - некоторые -- нет. + Некоторые из них базируются на коде GNU, а + некоторые -- нет. - Система X Window, отвечающая за графический интерфейс. - - Система X Window, которая используется в большинстве версий BSD, - поддерживается одним из двух различных проектов, либо проектом &xfree86;, либо проектом X.Org. Речь идёт о том же - самом коде, что используется в Linux. BSD, как правило, не делает - упор на какую-то специфическую графическую среду, - например, GNOME или KDE, хотя обе они доступны. + Система X Window, отвечающая за графический интерфейс. + + Система X Window, которая используется в большинстве версий BSD, + поддерживается одним из двух различных проектов, либо проектом &xfree86;, либо проектом X.Org. Речь идёт о том же + самом коде, что используется в Linux. BSD, как правило, не делает + упор на какую-то специфическую графическую среду, + например, GNOME или KDE, хотя обе они доступны. - Множество разных других прикладных и системных программ. + Множество разных других прикладных и системных программ. - + Что, настоящий &unix;? Операционные системы BSD не являются клонами друг друга. Они лишь потомки общего предка, ОС &unix; от AT&T Research, которая также дала начало современной ОС &unix; System V. Это факт может удивить, если вспомнить, что AT&T никогда не открывала исходные коды своих разработок. Действительно, &unix; никогда не был программным обеспечением с открытым исходным кодом, и в законном смысле BSD определённо НЕ &unix;. Но с другой стороны, в AT&T активно использовали чужие разработки, например программное обеспечение, разрабатываемое Группой по Исследованиям в области Информатики (CSRG) Калифорнийского Университета в Беркли. С 1976 CSRG выпускала свой код на магнитных лентах под названием Berkely Software Distribution, сокращённо BSD. Изначально дистрибутивы BSD представляли собой наборы пользовательских программ, и так было до тех пор, пока CSRG не заключила контракт с Агентством по Перспективным Проектам при Министерстве Обороны США (DARPA). Целью контракта было обновление коммуникационных протоколов, на которых держалась компьютерная сеть агентства -- ARPANET. Новое семейство протоколов получило имя Internet Protocols или TCP/IP, по названиям двух основных протоколов. Их первая широко известная реализация была выпущена в составе 4.2BSD в 1982 году. В течение восьмидесятых годов образовалось несколько компаний по производству рабочих станций. Многие из них предпочли купить лицензию на &unix;, нежели разрабатывать своё ПО с нуля. Следует отметить компанию Sun, которая поступила именно таким образом и на основе 4.2BSD выпустила свою операционную систему &sunos;. Когда AT&T тоже решила заняться коммерческой продажей своей ОС &unix;, появилась на свет несколько аскетичная реализация под названием System III, за которой в скором времени последовала System V. Интересно, что эти версии не содержали в себе собственной поддержки работы в сети и использовали код BSD, в том числе реализацию TCP/IP и набор утилит, среди которых следует выделить оболочку csh и текстовый редактор vi. Все эти добавки совместно получили название Berkely Extensions. Дистрибутив BSD содержал код, принадлежавший AT&T, и, следовательно, требовал лицензии. К 1990 году финансирование CSRG прекратилось, и группа была распущена. Кое-кто из бывших членов группы решил опубликовать код BSD отдельно от закрытого кода AT&T. В концов концов это удалось, и так появилась на свет версия Networking Tape 2 или Net/2. Net/2 не была законченной, цельной операционной системой: около 20% кода ядра отсутствовало. Один из членов CSRG, William F. Jolitz, дописал недостающий код и опубликовал результат в начале 1992 года под именем 386BSD. В то же самое время другая группа бывших членов CSRG организовала коммерческую компанию Berkeley Software Design Inc. и выпустила бета-версию операционной системы BSD/386, которая базировалась на том же самом коде. Позже это название было изменено на BSD/OS. 386BSD так никогда и не стала полноценной операционной системой. Зато в 1993 году из неё выделились два проекта: NetBSD и FreeBSD. Изначально разработчики разделились на два лагеря из-за расхождений во мнениях относительно того, сколько же ещё можно ждать улучшений в 386BSD. В начале года образовалась NetBSD, а первая версия FreeBSD была готова только к его концу. Время шло, и технические различия возрастали. Вдобавок проекты поставили перед собой разные цели, как будет показано ниже. В 1996 году от NetBSD отделился ещё один проект — OpenBSD, а в 2003 году от FreeBSD отделилась DragonFlyBSD. - + Почему BSD недостаточно известна? Действительно, существует ряд причин этому недоразумению: - Разработчики BSD часто больше заинтересованы в качестве - своего кода и заняты его шлифовкой, а не - рекламой. + Разработчики BSD часто больше заинтересованы в качестве + своего кода и заняты его шлифовкой, а не + рекламой. - По большому счёту Linux своей популярностью обязан - прежде всего внешним по отношению к проекту факторам, - например средствам массовой информации и компаниям, которые - решили сделать бизнес на предоставлении услуг пользователям - Linux. + По большому счёту Linux своей популярностью обязан + прежде всего внешним по отношению к проекту факторам, + например средствам массовой информации и компаниям, которые + решили сделать бизнес на предоставлении услуг пользователям + Linux. - Разработчики BSD, как правило, более опытны, чем - разработчики Linux, и в силу этого часто уделяют меньше - внимания облегчению жизни простым пользователям. Новичок - чувствует себя более комфортно в среде Linux. + Разработчики BSD, как правило, более опытны, чем + разработчики Linux, и в силу этого часто уделяют меньше + внимания облегчению жизни простым пользователям. Новичок + чувствует себя более комфортно в среде Linux. - В 1992 году компания AT&T подала в суд на BSDI, компанию-поставщика - ОС BSD/386. Основным пунктом обвинения было то, что BSD/386 - содержала в себе закрытый код, принадлежавший AT&T. - Дело вроде бы уладили за пределами суда в 1994-ом, но целая - серия вторичных тяжб и по сей день отравляет жизнь многим - людям. Совсем недавно, в марте 2000, в Internet была - опубликована статья, утверждавшая, что судебное - разбирательство окончательно завершено (recently - settled). - - В результате разбирательства прояснился вопрос с - названиями: если в 80-х годах BSD была известна под именем - BSD &unix;, то с исключением последних следов - кода, принадлежавшего AT&T, BSD потеряла право - называться &unix;. Вы можете заметить этот факт по - изменившимся заглавиям книг: операционная система - 4.3BSD &unix; и операционная система - 4.4BSD. + В 1992 году компания AT&T подала в суд на BSDI, компанию-поставщика + ОС BSD/386. Основным пунктом обвинения было то, что BSD/386 + содержала в себе закрытый код, принадлежавший AT&T. + Дело вроде бы уладили за пределами суда в 1994-ом, но целая + серия вторичных тяжб и по сей день отравляет жизнь многим + людям. Совсем недавно, в марте 2000, в Internet была + опубликована статья, утверждавшая, что судебное + разбирательство окончательно завершено (recently + settled). + + В результате разбирательства прояснился вопрос с + названиями: если в 80-х годах BSD была известна под именем + BSD &unix;, то с исключением последних следов + кода, принадлежавшего AT&T, BSD потеряла право + называться &unix;. Вы можете заметить этот факт по + изменившимся заглавиям книг: операционная система + 4.3BSD &unix; и операционная система + 4.4BSD. - Существует мнение, что проекты BSD сильно отличаются и, в - добавок, воюют между собой. Статья - в Wall Street Journal называет это - балканизацией среди проектов BSD. Можно - утверждать, что такое мнение, как и описанная судебная - тяжба, основывается прежде всего на событиях давно минувших - дней. + Существует мнение, что проекты BSD сильно отличаются и, в + добавок, воюют между собой. Статья + в Wall Street Journal называет это + балканизацией среди проектов BSD. Можно + утверждать, что такое мнение, как и описанная судебная + тяжба, основывается прежде всего на событиях давно минувших + дней. - + Сравнение BSD и Linux В чём заключается главная разница, к примеру, между Debian Linux и FreeBSD? Для среднего пользователя она на удивление мала: оба продукта представляют собой &unix;-подобные операционные системы. Оба продукта разрабатываются на некоммерческой основе (это не относится к некоторым другим дистрибутивам Linux). В этом разделе мы рассмотрим BSD в сравнении с Linux. Всё сказанное в основном будет касаться FreeBSD, которой принадлежит около 80% всех инсталляций BSD в мире, хотя отличия от NetBSD, OpenBSD и DragonFlyBSD в рамках предмета данной статьи незначительны. Кому принадлежит BSD? Нельзя сказать, что какой-то конкретный человек или - корпорация владеет BSD. Разработка и распространение ведутся - группой высококвалифицированных и преданных проекту - специалистов со всего мира. Некоторые компоненты BSD - представляют собой отдельные проекты с открытым кодом со своими - законами и коллективами разработчиков. + корпорация владеет BSD. Разработка и распространение ведутся + группой высококвалифицированных и преданных проекту + специалистов со всего мира. Некоторые компоненты BSD + представляют собой отдельные проекты с открытым кодом со своими + законами и коллективами разработчиков. Как выглядит процесс разработки и обновления BSD? Ядра BSD используют Open Source модель разработки. Каждый - проект поддерживает публично доступное дерево - исходников с помощью Concurrent Versions - System (CVS). Это дерево содержит абсолютно весь - исходный код проекта, а также документацию и вспомогательные - файлы. CVS позволяет пользователям получить копию дерева - любой версии системы. + проект поддерживает публично доступное дерево + исходников с помощью Concurrent Versions + System (CVS). Это дерево содержит абсолютно весь + исходный код проекта, а также документацию и вспомогательные + файлы. CVS позволяет пользователям получить копию дерева + любой версии системы. Огромное число людей со всего мира участвуют в - совершенствовании BSD. Все они разделены на три - группы: + совершенствовании BSD. Все они разделены на три + группы: - - Контрибуторы - пишут код или документацию. Они не могут добавлять или - изменять код непосредственно в дереве исходников проекта. - Это привилегия особым образом зарегистрированных - разработчиков, или коммиттеров - (committers), которые просматривают и тестируют - присылаемый им код и включают его в дерево. - - - - Коммиттеры являются разработчиками, - которые имеют доступ на запись в дерево - исходных кодов проекта. Чтобы стать коммиттером, человек - должен проявить себя в той области, в которой он хочет - работать. - - Каждый коммиттер по своему собственному усмотрению решает, - нужно ли ему подтверждение правильности планируемых - изменений от других разработчиков или нет. В общем - случае опытный коммиттер может вносить очевидно выгодные - изменения ни с кем не советуясь. К примеру, коммиттер - проекта документации может исправлять опечатки или - грамматические ошибки в документах без предварительного - согласования. Напротив, далеко идущие или просто сложные - изменения настоятельно рекомендуется представлять к - обсуждению перед окончательным внесением в дерево. Бывают - крайние случаи, когда член Core Team, выполняющий функцию - архитектора проекта, может санкционировать немедленную - отмену или откат - каких-то изменений в дереве. Все коммиттеры обязательно - получают уведомление о каждом изменении в дереве по - электронной почте, так что их невозможно сохранить в - тайне. - - - - Правление (Core Team). В проектах - FreeBSD и NetBSD имеются управляющие советы, которые занимаются - координационной деятельностью. Их роль, права и обязанности не - всегда чётко определены. Необязательно (хотя в порядке вещей) - быть коммиттером для того, чтобы входить в состав Core - Team. Правила, которым следует Core Team, различаются - между проектами, но в общем случае члены Core Team - определяют общее направление развития системы в большей - степени, чем все остальные разработчики. - + + Контрибуторы + пишут код или документацию. Они не могут добавлять или + изменять код непосредственно в дереве исходников проекта. + Это привилегия особым образом зарегистрированных + разработчиков, или коммиттеров + (committers), которые просматривают и тестируют + присылаемый им код и включают его в дерево. + + + + Коммиттеры являются разработчиками, + которые имеют доступ на запись в дерево + исходных кодов проекта. Чтобы стать коммиттером, человек + должен проявить себя в той области, в которой он хочет + работать. + + Каждый коммиттер по своему собственному усмотрению решает, + нужно ли ему подтверждение правильности планируемых + изменений от других разработчиков или нет. В общем + случае опытный коммиттер может вносить очевидно выгодные + изменения ни с кем не советуясь. К примеру, коммиттер + проекта документации может исправлять опечатки или + грамматические ошибки в документах без предварительного + согласования. Напротив, далеко идущие или просто сложные + изменения настоятельно рекомендуется представлять к + обсуждению перед окончательным внесением в дерево. Бывают + крайние случаи, когда член Core Team, выполняющий функцию + архитектора проекта, может санкционировать немедленную + отмену или откат + каких-то изменений в дереве. Все коммиттеры обязательно + получают уведомление о каждом изменении в дереве по + электронной почте, так что их невозможно сохранить в + тайне. + + + + Правление (Core Team). В проектах + FreeBSD и NetBSD имеются управляющие советы, которые занимаются + координационной деятельностью. Их роль, права и обязанности не + всегда чётко определены. Необязательно (хотя в порядке вещей) + быть коммиттером для того, чтобы входить в состав Core + Team. Правила, которым следует Core Team, различаются + между проектами, но в общем случае члены Core Team + определяют общее направление развития системы в большей + степени, чем все остальные разработчики. + Такое положение вещей отличается от принятого в Linux: - - Не существует человека, который бы контролировал - содержимое системы. На практике значение этого отличия - оказывается переоценённым, так как Ведущий Архитектор - может всегда потребовать откат изменений. Ко всему - прочему, в проекте Linux на современном этапе изменения в - код вносятся тоже не одним, а несколькими людьми. - - - - С другой стороны, существует - центральное хранилище (repository), откуда можно получить - полный код всей системы, причём как современных, так и - предыдущих версий. - - - - Проекты BSD являются цельными Операционными - Системами, а не просто ядрами. Это различие тоже - иногда переоценивают: ни BSD, ни Linux не представляют - ценности без приложений, а они порой одни и те же в обеих - средах. - - - - В результате формализованной процедуры поддержки - единого дерева исходников в CVS процесс разработки BSD - является полностью открытым, и мы получаем возможность - доступа к любой версии системы по номеру или по дате. CVS - также очень хорошо подходит для последовательных изменений - в коде: к примеру, хранилище кода FreeBSD обновляется - около ста раз за день, и большинство этих изменений весьма - малы и незначительны в отдельности друг от друга. - + + Не существует человека, который бы контролировал + содержимое системы. На практике значение этого отличия + оказывается переоценённым, так как Ведущий Архитектор + может всегда потребовать откат изменений. Ко всему + прочему, в проекте Linux на современном этапе изменения в + код вносятся тоже не одним, а несколькими людьми. + + + + С другой стороны, существует + центральное хранилище (repository), откуда можно получить + полный код всей системы, причём как современных, так и + предыдущих версий. + + + + Проекты BSD являются цельными Операционными + Системами, а не просто ядрами. Это различие тоже + иногда переоценивают: ни BSD, ни Linux не представляют + ценности без приложений, а они порой одни и те же в обеих + средах. + + + + В результате формализованной процедуры поддержки + единого дерева исходников в CVS процесс разработки BSD + является полностью открытым, и мы получаем возможность + доступа к любой версии системы по номеру или по дате. CVS + также очень хорошо подходит для последовательных изменений + в коде: к примеру, хранилище кода FreeBSD обновляется + около ста раз за день, и большинство этих изменений весьма + малы и незначительны в отдельности друг от друга. + Версии BSD FreeBSD, NetBSD и OpenBSD предоставляет миру три различных варианта - системы. Как и в Linux, версиям присваиваются номера, - например 1.4.1 или 3.5. В добавок, номер версии имеет суффикс - -- обозначение варианта, которое указывает на цели той или - иной версии. + системы. Как и в Linux, версиям присваиваются номера, + например 1.4.1 или 3.5. В добавок, номер версии имеет суффикс + -- обозначение варианта, которое указывает на цели той или + иной версии. - - Версия для разработчиков носит название - CURRENT. FreeBSD присваивает ей и + + Версия для разработчиков носит название + CURRENT. FreeBSD присваивает ей и номер, например FreeBSD 5.0-CURRENT. NetBSD использует чуть-чуть другую схему наименований и добавляет к номеру однобуквенный суффикс, обозначающий изменения во - внутренних интерфейсах. Пример: NetBSD 1.4.3G. OpenBSD не - нумерует разрабатываемую версию - (OpenBSD-current). Все новые разработки - производятся именно на этой ветке (branch) - системы. - - - - Через определённые интервалы от 3 до 6 месяцев проект - выпускает версию RELEASE, которая - распространяется на CD-ROM и доступна для скачивания с серверов - FTP. Примерами таких версий могут служить OpenBSD - 2.6-RELEASE и NetBSD 1.4-RELEASE. Этот вариант - предназначен для конечных пользователей. NetBSD также - предоставляет так называемые исправленные релизы - (patch releases), обозначаемые третьей цифрой в - номере, например NetBSD 1.4.2. - - - - По мере обнаружения ошибок в версии RELEASE - необходимые исправления вносятся в дерево CVS. - Получающаяся система в проекте FreeBSD носит название - STABLE, а в NetBSD и OpenBSD - продолжает называться RELEASE. Некоторые мелкие улучшения - тоже иногда вносятся в эту версию после продолжительного - периода тестирования в CURRENT. - + внутренних интерфейсах. Пример: NetBSD 1.4.3G. OpenBSD не + нумерует разрабатываемую версию + (OpenBSD-current). Все новые разработки + производятся именно на этой ветке (branch) + системы. + + + + Через определённые интервалы от 3 до 6 месяцев проект + выпускает версию RELEASE, которая + распространяется на CD-ROM и доступна для скачивания с серверов + FTP. Примерами таких версий могут служить OpenBSD + 2.6-RELEASE и NetBSD 1.4-RELEASE. Этот вариант + предназначен для конечных пользователей. NetBSD также + предоставляет так называемые исправленные релизы + (patch releases), обозначаемые третьей цифрой в + номере, например NetBSD 1.4.2. + + + + По мере обнаружения ошибок в версии RELEASE + необходимые исправления вносятся в дерево CVS. + Получающаяся система в проекте FreeBSD носит название + STABLE, а в NetBSD и OpenBSD + продолжает называться RELEASE. Некоторые мелкие улучшения + тоже иногда вносятся в эту версию после продолжительного + периода тестирования в CURRENT. + Linux, напротив, поддерживает два различных - дерева исходников, которые называются соответственно - стабильной версией и версией для разработчиков. Стабильные - версии имеют чётный вторичный номер, например 2.0, 2.2 или - 2.4. Версии для разработчиков используют нечётные номера, - такие как 2.1, 2.3 или 2.5. Во обоих случаях, к двойному - номеру версии добавляется ещё одно число, указывающее на - конкретный релиз. Стоит также отметить, что каждый поставщик - предоставляет свой собственный вариант пользовательских - программ (userland), так что имя дистрибутива тоже имеет - значение. Естественно, что поставщики нумеруют свои изделия - каждый по-своему, и, таким образом, мы получаем что-то вроде - TurboLinux 6.0 с ядром 2.2.14. + дерева исходников, которые называются соответственно + стабильной версией и версией для разработчиков. Стабильные + версии имеют чётный вторичный номер, например 2.0, 2.2 или + 2.4. Версии для разработчиков используют нечётные номера, + такие как 2.1, 2.3 или 2.5. Во обоих случаях, к двойному + номеру версии добавляется ещё одно число, указывающее на + конкретный релиз. Стоит также отметить, что каждый поставщик + предоставляет свой собственный вариант пользовательских + программ (userland), так что имя дистрибутива тоже имеет + значение. Естественно, что поставщики нумеруют свои изделия + каждый по-своему, и, таким образом, мы получаем что-то вроде + TurboLinux 6.0 с ядром 2.2.14. Какие существуют варианты BSD? В отличие от многочисленных дистрибутивов Linux, в мире существует - лишь четыре крупных BSD проекта с открытыми исходными кодами. - Каждый из них поддерживает своё собственное дерево исходников - и своё собственное ядро. На практике однако оказывается, - что пользовательские части (userland) различных BSD отличаются - гораздо меньше, чем у разных дистрибутивов Linux. + лишь четыре крупных BSD проекта с открытыми исходными кодами. + Каждый из них поддерживает своё собственное дерево исходников + и своё собственное ядро. На практике однако оказывается, + что пользовательские части (userland) различных BSD отличаются + гораздо меньше, чем у разных дистрибутивов Linux. Цели каждого из проектов не поддаются чёткой формулировке. - Различия между ними весьма субъективны. В основном, + Различия между ними весьма субъективны. В основном, - - проект FreeBSD нацелен на повышение производительности - и простоту в использовании конечными пользователями. - FreeBSD очень ценят в среде Web-хостеров. Эта ОС работает - на нескольких аппаратных платформах, в том числе системах на базе - процессоров i386 (ПК), системах, построенных на - 64-разрядных процессорах AMD, системах &ultrasparc;, системах, - работающие на базе процессоров Alpha компании Compaq, а также - системах, построенные по спецификациям NEC PC-98. Число - пользователей FreeBSD значительно превышает число пользователей - других проектов. - - - - проект NetBSD ставит целью максимальную мобильность - (или переносимость) кода: девиз конечно NetBSD - работает на этом. NetBSD поддерживает машины от - крошечных палмтопов до огромных серверов и использовалась - NASA в космических миссиях. Это хороший выбор для старой - не-Intel аппаратуры. - - - - проект OpenBSD нацелен на безопасность и - чистоту кода. С помощью комбинирования - концепций открытых исходников и скрупулёзного анализа кода - проект демонстрирует чудеса корректности работы системы. В - силу названных причин совершенно естественно, что OpenBSD - выбирают организации, для которых очень важна защита - информации, например банки, фондовые биржи и различные - департаменты правительства США. Также как и NetBSD, - проект поддерживает целый ряд аппаратных платформ. - - - - Целью DragonFlyBSD является достижение высокой - производительности и масштабируемости в любой ситуации—как - для одиночных однопроцессорных, так и крупных кластерных систем. - DragonFlyBSD ставит перед собой несколько долгосрочных технических - задач, но основной упор делается на создание инфраструктуры для - работы с SMP, которая была бы проста для понимания, поддержки и - ведения в ней разработок. - + + проект FreeBSD нацелен на повышение производительности + и простоту в использовании конечными пользователями. + FreeBSD очень ценят в среде Web-хостеров. Эта ОС работает + на нескольких аппаратных платформах, в том числе системах на базе + процессоров i386 (ПК), системах, построенных на + 64-разрядных процессорах AMD, системах &ultrasparc;, системах, + работающие на базе процессоров Alpha компании Compaq, а также + системах, построенные по спецификациям NEC PC-98. Число + пользователей FreeBSD значительно превышает число пользователей + других проектов. + + + + проект NetBSD ставит целью максимальную мобильность + (или переносимость) кода: девиз конечно NetBSD + работает на этом. NetBSD поддерживает машины от + крошечных палмтопов до огромных серверов и использовалась + NASA в космических миссиях. Это хороший выбор для старой + не-Intel аппаратуры. + + + + проект OpenBSD нацелен на безопасность и + чистоту кода. С помощью комбинирования + концепций открытых исходников и скрупулёзного анализа кода + проект демонстрирует чудеса корректности работы системы. В + силу названных причин совершенно естественно, что OpenBSD + выбирают организации, для которых очень важна защита + информации, например банки, фондовые биржи и различные + департаменты правительства США. Также как и NetBSD, + проект поддерживает целый ряд аппаратных платформ. + + + + Целью DragonFlyBSD является достижение высокой + производительности и масштабируемости в любой ситуации—как + для одиночных однопроцессорных, так и крупных кластерных систем. + DragonFlyBSD ставит перед собой несколько долгосрочных технических + задач, но основной упор делается на создание инфраструктуры для + работы с SMP, которая была бы проста для понимания, поддержки и + ведения в ней разработок. + Следует упомянуть ещё две операционных системы BSD &unix;, - которые не предоставляют публичного доступа к своим исходным - кодам. Это BSD/OS компании BSDI и &macos; X компании Apple. + которые не предоставляют публичного доступа к своим исходным + кодам. Это BSD/OS компании BSDI и &macos; X компании Apple. - - BSD/OS являлась самым старым из потомков 4.4BSD. - Исходный код был недоступен широкой публике, хотя лицензия на - него стоила относительно немного. BSD/OS во многом похожа - на FreeBSD. Через два года после поглощения BSDi компанией Wind - River Systems, BSD/OS перестала существовать как отдельный продукт. - Поддержку и исходный код ещё можно получить у Wind River, но все - новые разработки сосредоточены на встраиваемой операционной - системой VxWorks. - - - - &macos; - X — это самая последняя версия операционной - системы для линейки компьютеров &macintosh; компании Apple Computer Inc. - Ядро этой операционной системы, Darwin, - построенное на коде BSD, доступно в виде полностью - функциональной операционной системы с открытым кодом для - компьютеров архитектур x86 и PPC. Однако код графической системы - Aqua/Quartz и многих других проприетарных компонентов &macos; X - остаётся закрытым. Несколько разработчиков Darwin являются также - коммиттерами FreeBSD и наоборот. - + + BSD/OS являлась самым старым из потомков 4.4BSD. + Исходный код был недоступен широкой публике, хотя лицензия на + него стоила относительно немного. BSD/OS во многом похожа + на FreeBSD. Через два года после поглощения BSDi компанией Wind + River Systems, BSD/OS перестала существовать как отдельный продукт. + Поддержку и исходный код ещё можно получить у Wind River, но все + новые разработки сосредоточены на встраиваемой операционной + системой VxWorks. + + + + &macos; + X — это самая последняя версия операционной + системы для линейки компьютеров &macintosh; компании Apple Computer Inc. + Ядро этой операционной системы, Darwin, + построенное на коде BSD, доступно в виде полностью + функциональной операционной системы с открытым кодом для + компьютеров архитектур x86 и PPC. Однако код графической системы + Aqua/Quartz и многих других проприетарных компонентов &macos; X + остаётся закрытым. Несколько разработчиков Darwin являются также + коммиттерами FreeBSD и наоборот. + В чём отличие между лицензией BSD и Общественной - Лицензией GNU (GPL)? + Лицензией GNU (GPL)? Linux распространяется на условиях лицензии - GNU General - Public License (GPL), русский перевод которой тоже - существует. - Эта лицензия имеет целью уничтожить программное обеспечение с - закрытым исходным кодом. В частности, любое ПО, базирующееся - на продукте, выпущенном на условиях лицензии GPL, тоже должно - поставляться с исходными кодами по первому требованию. - Лицензия - BSD не накладывает таких жёстких ограничений: - разрешается распространение программного обеспечения в - двоичном виде (binary-only). Этот факт привлекает - разработчиков встроенных (embedded) приложений. + GNU General + Public License (GPL), русский перевод которой тоже + существует. + Эта лицензия имеет целью уничтожить программное обеспечение с + закрытым исходным кодом. В частности, любое ПО, базирующееся + на продукте, выпущенном на условиях лицензии GPL, тоже должно + поставляться с исходными кодами по первому требованию. + Лицензия + BSD не накладывает таких жёстких ограничений: + разрешается распространение программного обеспечения в + двоичном виде (binary-only). Этот факт привлекает + разработчиков встроенных (embedded) приложений. Что ещё следует знать? То обстоятельство, что приложений для BSD существует - меньше, чем для Linux, вынудило разработчиков BSD позаботиться - о создании дополнительной совместимости с Linux, которая - позволяет запускать программы для Linux на компьютере, - работающем под BSD. Программный пакет, обеспечивающий - совместимость, включает в себя как ядерную реализацию - системных вызовов Linux, так и разнообразные файлы, - необходимые программам, скомпилированным для Linux, например - библиотеку C. Разница в скорости выполнения Linux-приложений - на машине с Linux и на такой же машине с BSD незаметна. + меньше, чем для Linux, вынудило разработчиков BSD позаботиться + о создании дополнительной совместимости с Linux, которая + позволяет запускать программы для Linux на компьютере, + работающем под BSD. Программный пакет, обеспечивающий + совместимость, включает в себя как ядерную реализацию + системных вызовов Linux, так и разнообразные файлы, + необходимые программам, скомпилированным для Linux, например + библиотеку C. Разница в скорости выполнения Linux-приложений + на машине с Linux и на такой же машине с BSD незаметна. Принцип вся система от одного поставщика, - используемый в BSD, приводит к упрощению процедур обновления - системы по сравнению с многими дистрибутивами Linux. BSD - предоставляет специальные модули совместимости с устаревшими - версиями системных библиотек, и таким образом делает возможным - запуск откомпилированных несколько лет назад программ на - обновлённой системе. + используемый в BSD, приводит к упрощению процедур обновления + системы по сравнению с многими дистрибутивами Linux. BSD + предоставляет специальные модули совместимости с устаревшими + версиями системных библиотек, и таким образом делает возможным + запуск откомпилированных несколько лет назад программ на + обновлённой системе. Что же выбрать, BSD или Linux? Во что выливается всё вышесказанное на практике? Кому - предназначена BSD, и кому -- Linux? + предназначена BSD, и кому -- Linux? Это действительно очень сложный вопрос. Приведём несколько - советов, которые призваны помочь Вам с выбором: + советов, которые призваны помочь Вам с выбором: - - Не тронь, пока работает: если Вы уже - успешно используете какую-нибудь Open Source ОС, и она Вас - устраивает, то пожалуй не стоит ничего менять. - - - - Системы BSD, в особенности FreeBSD, могут - демонстрировать большую по сравнению с Linux - производительность. Но это вовсе не универсальное - правило. Во многих случаях эта разница не заметна, если - вообще есть. Иногда Linux может работать лучше, чем - FreeBSD. - - - - В общем случае, у систем BSD очень хорошая репутация, - когда дело касается надёжности. Это, в основном, связано - с более зрелой базой исходных кодов. - - - - Лицензия BSD иногда может быть более привлекательной, - нежели GPL. - - - - В BSD может работать большинство исполнимых файлов Linux, - однако в Linux выполнимые файлы BSD запускаться не будут. Во - многих реализациях BSD могут также выполняться двоичные файл и - других &unix;-подобных систем. Таким образом, BSD может предложить - более простой способ перехода с других систем, чем Linux. - + + Не тронь, пока работает: если Вы уже + успешно используете какую-нибудь Open Source ОС, и она Вас + устраивает, то пожалуй не стоит ничего менять. + + + + Системы BSD, в особенности FreeBSD, могут + демонстрировать большую по сравнению с Linux + производительность. Но это вовсе не универсальное + правило. Во многих случаях эта разница не заметна, если + вообще есть. Иногда Linux может работать лучше, чем + FreeBSD. + + + + В общем случае, у систем BSD очень хорошая репутация, + когда дело касается надёжности. Это, в основном, связано + с более зрелой базой исходных кодов. + + + + Лицензия BSD иногда может быть более привлекательной, + нежели GPL. + + + + В BSD может работать большинство исполнимых файлов Linux, + однако в Linux выполнимые файлы BSD запускаться не будут. Во + многих реализациях BSD могут также выполняться двоичные файл и + других &unix;-подобных систем. Таким образом, BSD может предложить + более простой способ перехода с других систем, чем Linux. + Кто предоставляет техническую поддержку, обслуживание и - обучение для систем BSD? + обучение для систем BSD? BSDi / FreeBSD - Mall, Inc. уже около десяти лет предлагает контракты на - поддержку FreeBSD. + Mall, Inc. уже около десяти лет предлагает контракты на + поддержку FreeBSD. Кроме того, каждый из проектов постоянно обновляет список - консультантов, которые оказывают поддержку за отдельную плату: FreeBSD, - - NetBSD и OpenBSD. + консультантов, которые оказывают поддержку за отдельную плату: FreeBSD, + + NetBSD и OpenBSD.
diff --git a/ru_RU.KOI8-R/articles/hats/article.sgml b/ru_RU.KOI8-R/articles/hats/article.sgml index 14e57647c2..e3938e6d86 100644 --- a/ru_RU.KOI8-R/articles/hats/article.sgml +++ b/ru_RU.KOI8-R/articles/hats/article.sgml @@ -1,133 +1,133 @@ %articles.ent; ]>
Работа должностных лиц Уорнер Лош Текст предоставил $FreeBSD$ 2002 2003 Уорнер Лош Этот документ не является официальным заявлением Правления, но персональной интерпретацией одного из его членов позиции Правления, как действительного члена Правления и как бывшего руководителя департамента безопасности. Это всего лишь общие указания, а не палка для битья. Как &man.style.9; выступает в роли общего руководства для написания исходного кода, так и этот документ не претендует на роль тесного костюма. Когда управляющий совет назначает кому-то должность, его участники полагают, что человек будет отвечать за определённую часть дерева исходных текстов. Правление считает, что назначенной персоне будет принадлежать последнее слово в этой области кода, либо человек будет понимать, что его квалификации не хватает, и обратится за квалифицированной помощью. Правление рассчитывает на то, что этот человек будет руководить разработками этой части кода. Иногда это означает ведение ежедневной проактивной деятельности, а в некоторых случаях предполагает реактивный подход к просмотру кода, размещаемого в дереве исходных текстов. Когда разработчики предлагают патчи, которые потенциально могут отразиться на данной области дерева исходных текстов, Правление ожидает, что должностное лицо или его полномочный представитель просмотрят эти патчи. Правление полагает, что должностное лицо будет работать с человеком, предложившим патч, для решения проблем, которые могут возникнуть с этим патчем. Правление считает, что должностное лицо предложит решения и будет работать с разработчиком до момента достижения компромисса. Правление ожидает от должностного лица корректного поведения. В порядке вещей требовать от должностных лиц следования обычным правилам проекта при просмотре патчей (к примеру, что они в целом соответствуют &man.style.9; или общепринятому формату файла, что изменения в оформлении и содержимом файла будут выполняться отдельно, и так далее). При возникновении разногласий Правление ожидает, что должностное лицо приложит все усилия для нахождения компромисса либо другого способа разрешения конфликта. Должностное лицо должно общаться со всеми участниками корректно. Правление понимает, что в особо острых случаях должностному лицу требуется большая дубинка и возможность сказать нет, это изменение нам не подходит и не может быть включено в исходный код (или должно быть отменено). Правление рассматривает это проявление власти как последнее из возможных средств, и не будет одобрять действия должностных лиц, применяющих его слишком часто или в качестве первой реакции. Зачастую реальная жизнь пересекается с возможностью должностного лица по выполнению своих обязанностей. Условием, соблюдение которого Правление обычно требует от должностного лица, является наличие представителя, который может выполнять работу при отсутствии самого должностного лица. Ожидается, что этот представитель является активным участником той команды, которой руководит должностное лицо, и хорошо знает все проблемы, относящиеся к той части дерева исходных текстов, которой занимается должностное лицо. Предполагается, что представитель сможет работать в отсутствие должностного лица. К примеру, представители руководителя департамента безопасности рассылают бюллетени безопасности, когда руководителя нет рядом. В особых случаях представитель может отложить решение вопроса до появления должностного лица, но это должно быть скорее исключением, чем правилом, особенно если должностное лицо должно вернуться только в далёком будущем. Должностные лица отвечают перед Правлением. Если они работают хорошо, то Правление оставляют их в покое. Если должностные лица с работой не справляются, то Правление может освободить их от занимаемой должности. Предполагается, что должностные лица работают с Правлением, если у него есть претензии к выполнению обязанностей должностных лиц. Должностные лица выполняют волю Правления. Иногда Правление выдвигает дополнительные и специфические требования к определённому должностному лицу, которые отличаются от требований ко всем остальным должностям. Эти условия со временем могут меняться. От коммиттеров и прочие лиц, работающих с должностными лицами, ожидается соблюдение общих норм поведения и проявление вежливости по отношению к должностным лицам. Предполагается, что они работают с должностным лицом и его группой доя выработки решения, подходящего всем. В случае, если компромисс не может быть достигнут, от коммиттеров ожидается тактичное следование решению, принятому должностным лицом. В исключительных случаях против этого решения может быть подана апелляция Правлению. Однако обычно Правление не отменяет решения должностных лиц, если только они не теряют доверия или объективности. Правление не является техническим советом, и назначает должностных лиц для выполнения функций технических советов небольших масштабов, чтобы обсуждения проходили в соответствующей среде. Если коммиттер считает, что должностное лицо превышает свои полномочия или часто грубит разработчикам, то они должны сообщить об этом Правлению. Эта проблема может иметь технический, социальный или процедурный характер, а может представлять собой некую комбинацию или подмножество всех указанных признаков. Правление рассмотрит ваш случай и вынесет своё решение. Правление рассматривает конкретные жалобы, а не претензии общего характера, так как их легче разрешить. Правление считает, что коммиттеры работают вместе над решением своих проблем в соответствующих списках рассылки. Должностное лицо и его группа должны относительно редко выступать в роли именно должностного лица, а обычно как просто рядовой коммиттер. (Одним из исключением из этого правила является должность руководителя департамента безопасности, который должен устранять уязвимости втайне, до момента объявления об их наличии.) Должностное лицо должно быть первым среди равных, а не председателем совета директоров.
diff --git a/ru_RU.KOI8-R/articles/hubs/article.sgml b/ru_RU.KOI8-R/articles/hubs/article.sgml index 4c8ea30de0..59cda73b5e 100644 --- a/ru_RU.KOI8-R/articles/hubs/article.sgml +++ b/ru_RU.KOI8-R/articles/hubs/article.sgml @@ -1,1151 +1,1151 @@ %articles.ent; ]>
Поддержка зеркал FreeBSD $FreeBSD$ Jun Kuriyama
kuriyama@FreeBSD.org
 Valentino Vaschetto
logo@FreeBSD.org
 Daniel Lang
dl@leo.org
 Ken Smith
kensmith@FreeBSD.org
 Дмитрий Морозовский Перевод на русский язык: &tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.general; Рабочий вариант статьи, описывающей процесс создания и поддержки зеркала FreeBSD и адресованной администраторам зеркал. Контактная информация Координаторы системы зеркал доступны по электронной почте по адресу mirror-admin@FreeBSD.org. Помимо этого, существует &a.hubs;. Требования к зеркалам FreeBSD Дисковое пространство Одним из наиболее важных требований является дисковое пространство. В зависимости от набора релизов, архитектур и степени полноты зеркала вам может потребоваться огромный объем диска. Не лишним будет помнить, что официальное зеркало, скорее всего, должно быть полным. Репозиторий CVS и веб-страницы всегда должны зеркалироваться полностью. Кроме того, учтите, что приводимые оценки объема относятся к состоянию на момент последнего редактирования данной статьи (&rel2.current;-RELEASE/&rel.current;-RELEASE). Дальнейший процесс разработки и последующие релизы только увеличат требуемый объем. Кроме того, разумно будет зарезервировать некоторое (10-20%) дополнительное пространство спокойствия ради. Вот некоторые оценки объема: Полное зеркало FTP: 126 GB Репозиторий CVS: 2.7 GB Комплект изменений CTM: 1.8 GB Веб-страницы: 300 MB Требования к сетевой связности и пропускной способности Разумеется, у вас должно быть подключение к интернет. Требуемая пропускная способность ваших каналов зависит от предполагаемого профиля использования вашего зеркала. Если вы собираетесь копировать некоторые части FreeBSD для локального использования на вашей машине или в интранете, требования могут быть много мягче, чем для публичного зеркала. Для официального зеркала необходимая пропускная способность увеличивается еще больше. Мы можем дать лишь очень грубые оценки: Зеркало для локального доступа: фактически минимум не определен, но канал шириной менее 2 Mbps может сделать процесс обновления мучительно медленным. Неофициальное публичное зеркало: 34 Mbps выглядит неплохо для начала. Официальное зеркало: рекомендуется канал шириной более 100 Mbps; кроме того, ваша машина должна стоять как можно ближе к граничным маршрутизаторам вашей сети. Системные требования, процессор и память Эти требования в первую очередь определяются максимальным ожидаемым количеством клиентов (устанавливается администратором сервера). Также, на требуемые ресурсы влияет список сервисов, которые вы будете предоставлять. Зеркало FTP и/или HTTP не требуют особенно много ресурсов; значительно больше памяти и вычислительной производительности потребляют CVSup, rsync или AnonCVS. Особенно "прожорливым" по памяти является rsync; CVSup требует достаточной производительности процессора. Для предоставления доступа по AnonCVS хорошей идеей будет создание виртуальной файловой системы в памяти (MFS) по крайней мере 300 MB размером, так что учтите это при планировании. Вот некоторые советы по конфигурации аппаратной части сервера: Для умеренно посещаемого сайта, предоставляющего rsync, можно использовать процессор с частотой 800MHz - 1 GHz и по крайней мере 512MB памяти. Скорее всего, данная конфигурация может считаться минимальной для официального зеркала. Для регулярно посещаемого сайта вам потребуется больше памяти (хорошим стартом будет 2GB) и больше процессорной мощности, что может означать требование многопроцессорной (SMP) платформы. Кроме того, вам потребуется быстрая дисковая подсистема, в первую очередь, для работы с репозиторием CVS (крайне рекомендуем RAID). Контроллер SCSI, оборудованный собственной памятью, также может ощутимо ускорить процесс, поскольку большая часть сервисов связана с большим количеством дисковых запросов небольшого размера. Предоставляемые сервисы Всякое зеркало должно предоставлять набор основных сервисов. Помимо требуемого минимального набора, существуют дополнительные сервисы, которые администратор сервера может пожелать предоставлять. Этот раздел описывает, какие сервисы вы можете предоставлять, и какие действия для этого потребуются от вас. FTP (требуется для FTP зеркала) Это один из наиболее базовых сервисов; его предоставление требуется для каждого зеркала, распространяющего файлы FreeBSD по FTP. Доступ по FTP должен быть анонимным, и не должны применяться какие-либо ограничения по соотношению объема передано/принято (что вообще является, на наш взгляд, странным подходом). Закачка (upload) файлов на сервер не требуется (и должна быть запрещена в разделе FreeBSD). Кроме того, архив файлов FreeBSD должен быть доступен с путем /pub/FreeBSD. Для предоставления анонимного FTP доступа может быть использован целый ряд программ (перечислены в алфавитном порядке): /usr/libexec/ftpd: базовый FTP-даемон FreeBSD. Не забудьте прочитать &man.ftpd.8;. ftp/ncftpd: коммерческий пакет, свободен для использования в учебных целях. ftp/oftpd: FTP-даемон, написанный в основном с точки зрения защищенности. ftp/proftpd: Модульный и очень гибкий FTP-даемон. ftp/pure-ftpd: Еще один FTP-даемон, разработанный с позиций защищенности. ftp/twoftpd: См. предыдущий пункт. ftp/vsftpd: очень защищенный (very secure) ftpd. ftp/wu-ftpd: ftpd от Вашингтонского Университета (Washington University). Несколько потерял популярность из-за большого количества найденных в прошлом ошибок защиты. Если вы решите использовать его, помните о необходимости отслеживания обновлений. Наиболее популярными являются встроенный во FreeBSD ftpd, proftpd, wu-ftpd и, возможно, ncftpd. Прочие распространены среди существующих зеркал в существенно меньшей степени. Дополнительным поводом для рассмотрения может являться возможность гибко ограничивать количество одновременных соединений, что поможет вам удержать в нужных рамках потребление пропускной способности ваших каналов и машинные ресурсы. RSYNC (необязательный сервис для FTP зеркала) rsync часто используется для предоставления доступа к FTP-области FreeBSD, чтобы другие зеркала могли синхронизироваться по вашему. Протокол rsync во многом отличается от FTP, в частности, он гораздо гуманнее с точки зрения пропускной способности каналов, поскольку не требует передачи измененного файла целиком (передаются лишь различия). Взамен rsync требует значительных объемов памяти. Размер каждого процесса зависит от размера синхронизируемого модуля (в основном от количества директорий и файлов). rsync может использовать в качестве транспортного протокола rsh или ssh (по умолчанию); также, может использоваться внутренний протокол rsync (этот метод предпочтителен для публичных rsync-серверов). Поддерживается авторизация клиентов и различные ограничения. Для протокола rsync существует единственный пакет: net/rsync HTTP (требуется для веб-страниц, дополнителен для FTP зеркал) Если вы хотите поддерживать зеркало веб-страниц FreeBSD, вам потребуется веб-сервер, или httpd. Дополнительно, вы можете предоставлять HTTP доступ к FTP-набору файлов FreeBSD. Выбор веб-сервера остается на усмотрение администратора зеркала. Некоторые из наиболее популярных веб-серверов перечислены ниже. www/apache13: Apache — один из самых популярных веб-серверов, активно используемый проектом FreeBSD. Вы можете также использовать Apache нового поколения, доступный в коллекции портов как - www/apache2. + www/apache22. www/thttpd: Для обслуживания большого количества запросов к статическим документам сервер thttpd может оказаться более эффективным, чем Apache. thttpd отлично оптимизирован по производительности при работе под FreeBSD. www/boa: Boa — еще одна альтернатива thttpd и Apache. Этот сервер должен быть ощутимо более высокопроизводительным, чем Apache, для полностью статических страниц. На время написания данного документа, впрочем, он не так хорошо оптимизирован под FreeBSD, как thttpd. CVSup (желателен для зеркал репозитория CVS) CVSup предоставляет очень эффективный механизм распространения файлов. Он работает подобно rsync и был разработан специально для использования с репозиториями CVS. Если вы планируете предоставлять доступ к репозиторию CVS FreeBSD, стоит делать это посредством CVSup. Помимо этого, можно использовать AnonCVS, FTP, Rsync или HTTP, но использование CVSup наиболее разумно. Автором CVSup является &a.jdp;. CVSup непросто установить на платформе, отличной от FreeBSD, поскольку он написан на языке Modula-3 и требует соответствующего окружения. Джон Полстра создал усеченную версию M3, достаточную для работы CVSup, которую намного проще установить. Подробности можно прочитать здесь: Ezm3. Относящиеся к теме пакеты: net/cvsup: Порт CVSup (клиент и сервер), требующий для сборки пакет lang/ezm3. net/cvsup-mirror: Набор для CVSup-зеркала, требующий net/cvsup, и конфигурирующий его в процессе установки. Возможно, некоторым администраторам потребуется другой набор установок. Может также оказаться полезным пакет net/cvsup-without-gui. Если вы предпочитаете пакет, собранный статически, загляните по этой ссылке. Эта страница все еще описывает ошибку S1G. Возможно, в будущем Джон создаст универсальный сайт для загрузки статически собранных вариантов CVSup для различных платформ. При помощи CVSup можно распространять любые коллекции файлов (не только репозитории CVS), однако его конфигурация может быть непростой. Известно, что CVSup потребляет ощутимое количество процессорного времени как на сервере, так и на клиенте, поскольку сравнивает большое количество файлов. AnonCVS (дополнителен для зеркал репозитория CVS) Если вы копируете репозиторий CVS, можно дополнительно предоставить к нему анонимный доступ. Для начала, предупреждение: спрос на этот сервис не так уж велик, подготовка его требует некоторого опыта, и, наконец, вы должны знать, что делаете. Существует два основных способа удаленного доступа к репозиторию CVS: через pserver и через ssh (доступ через rsh мы рассматривать не будем). Для анонимного доступа наиболее подходит pserver; впрочем, некоторые сайты дают доступ и посредством ssh. Для последнего будет полезной специальная программа, предназначенная для использования в качестве шелла для учетной записи анонимного ssh-доступа. Она использует вызов chroot, поэтому репозиторий CVS должен располагаться внутри домашнего каталога анонимного пользователя, что приемлемо не для всех сайтов. Данное ограничение не распространяется на доступ через pserver, однако последний вариант может быть связан с дополнительным риском с точки зрения безопасности. Никаких дополнительных программ для обеспечения анонимного CVS-доступа не потребуется, поскольку &man.cvs.1; входит в базовую поставку FreeBSD. Вам нужно будет разрешить запуск cvs из inetd, для чего необходимо добавить в файл /etc/inetd.conf строку вида cvspserver stream tcp nowait root /usr/bin/cvs cvs -f -l -R -T /anoncvstmp --allow-root=/home/ncvs pserver Обратитесь к странице справочника &man.cvs.1; за дополнительной информацией по опциям. Кроме того, страницы info по CVS описывают, как удостовериться в том, что вы предоставляете доступ только для чтения. Рекомендуется создать непривилегированную учетную запись, желательно с именем anoncvs. Потребуется также создать файл passwd в каталоге /home/ncvs/CVSROOT и установить пароль (пустой или anoncvs) для пользователя anoncvs. Создание файловой системы /anoncvstmp в памяти не необходимо, но рекомендуется для ускорения работы: в ней &man.cvs.1; будет создавать временную структуру каталогов, которая не используется по завершении операции, но сильно замедляет работу, если требуются операции записи на реальный диск. Пример описания такой файловой системы в файле /etc/fstab: /dev/da0s1b /anoncvstmp mfs rw,-s=786432,-b=4096,-f=512,-i=560,-c=3,-m=0,nosuid,nodev 0 0 Эти установки (разумеется, тщательно подобранные) предложил &a.jdp;. Как вести зеркало FreeBSD Теперь вам известно, какая потребуется машина и как предоставлять сервисы, но не как получить их самому. :-) В этом разделе описывается процесс ведения зеркала и поддержания его в актуальном состоянии, в том числе какие инструменты использовать и какие сайты выбирать в качестве источников для синхронизации. FTP Файлы, доступные по FTP, составляют большую часть зеркала. Они включают дистрибутивные наборы, необходимые для установки по сети, ветви (branches), в которых отражено текущее состояние исходных текстов, образы ISO для записи компакт-дисков с дистрибутивами для установки, образами живых файловых систем и пакетами, дерево портов, исходные дистрибутивы для сборки портов и кучу готовых пакетов. И, разумеется, все вышеописанное — для разных версий FreeBSD и различных архитектур. При помощи программ для FTP-зеркалирования Для выкачивания файлов вы можете использовать программу FTP-зеркалирования. Существует довольно много таких, например: ftp/mirror ftp/ftpmirror ftp/emirror ftp/spegla ftp/omi и даже ftp/wget Ранее наиболее популярным вариантом был ftp/mirror, хотя из-за того, что эта программа написана на &man.perl.1;, существуют различные ограничения, в особенности при зеркалировании больших файловых структур, таких как FreeBSD. Утверждается, впрочем, что в текущей версии последняя проблема исправлена за счет дополнительного алгоритма сравнения структуры каталогов. Вообще говоря, протокол FTP не лучшим образом подходит для поддержки зеркала. Измененный файл передается целиком; кроме того, невозможно создание единого потока данных, который мог бы повысить эффективность передачи за счет большого TCP-окна. При помощи RSYNC Более эффективным будет синхронизация FTP-области при помощи rsync. Для этого следует установить пакет net/rsync, который был описан в разделе . Поскольку доступ по протоколу rsync не является обязательным, выбранный вами сайт может его не поддерживать. Возможно, вам придется немного поискать в сетевой окрестности зеркало, поддерживающее rsync. Поскольку от количества клиентов rsync ощутимо зависит загрузка сервера, большинство администраторов вводят ограничения доступа. Для поддержания зеркала вам следует связаться с администратором сайта, с которым вы будете синхронизироваться, для уточнения локальных правил и, возможно, для внесения в них исключения для вас (поскольку вы также поддерживаете зеркало). Строка для синхронизации FreeBSD по rsync выглядит примерно так: &prompt.user; rsync -vaz --delete ftp4.de.FreeBSD.org::FreeBSD/ /pub/FreeBSD/ Загляните в документацию по rsync, также доступную по адресу http://rsync.samba.org/ за дополнительной информацией по различным опциям rsync. Обратите внимание, что в случае синхронизации модуля целиком (а не отдельного каталога) необходимо явно указать результирующий каталог, потому что каталог с именем модуля (в данном случае "FreeBSD") не создается. Для поддержания актуальности вам потребуется создать скрипт для запуска подобной команды из &man.cron.8;. При помощи CVSup Немногие сайты, в первую очередь центральный ftp-master.FreeBSD.org предоставляют для синхронизации FTP-области доступ по протоколу CVSup. Вам потребуется клиент cvsup, предпочтительно из пакета net/cvsup (см. также ). Пример конфигурационного файла (supfile) для синхронизации с ftp-master.FreeBSD.org: # # FreeBSD archive supfile from master server # *default host=ftp-master.FreeBSD.org *default base=/usr *default prefix=/pub #*default release=all *default delete use-rel-suffix *default umask=002 # If your network link is a T1 or faster, comment out the following line. #*default compress FreeBSD-archive release=all preserve Судя по всему, синхронизация при помощи CVSup — лучший по эффективности способ поддержки зеркала, однако он доступен лишь с небольшого числа сайтов. Прочтите документацию по CVSup, например, &man.cvsup.1;, и обратите внимание на опцию : она может существенно уменьшить объем работы при синхронизации. Синхронизация репозитория CVS Как и в других случаях, репозиторий можно синхронизировать различными способами; однако, рекомендуемым является CVSup. Использование CVSup Программа CVSup уже была описана ранее ( и ). Здесь мы лишь приведем пример конфигурационного файла (supfile): # # FreeBSD CVS supfile from master server # *default host=cvsup-master.FreeBSD.org *default base=/usr *default prefix=/pub/FreeBSD/development/FreeBSD-CVS *default release=cvs *default delete use-rel-suffix *default umask=002 # If your network link is a T1 or faster, comment out the following line. #*default compress cvs-all Кроме того, можете использовать в качестве шаблона /usr/share/examples/cvsup. Не забудьте почитать полезную подсказку здесь. Другие методы Использование методов, отличных от CVSup, не рекомендуется. Тем не менее, мы кратко упомянем их. Поскольку большая часть зеркал дает доступ к репозиторию CVS в числе прочих файлов, доступных по FTP, по пути /pub/FreeBSD/development/FreeBSD-CVS, могут быть использованы: FTP RSYNC и даже HTTP Если вы найдете сайт, поддерживающий обновления по net/sup, можете использовать его. Впрочем, учитывая, что именно недостатки sup в свое время заставили Джона Полстру написать CVSup, данный метод никак не может быть рекомендован. Для синхронизации репозитория CVS не может быть использован AnonCVS, поскольку CVS не дает доступа к репозиторию напрямую, а лишь позволяет извлекать отдельные версии модулей. Зеркалирование страниц WWW Лучшим способом будет извлечение (check out) из репозитория CVS модуля www. При условии наличия у вас копии репозитория, все, что для этого потребуется — выполнить один раз команду &prompt.user; cvs -d /home/ncvs co www и сформировать задание для cron, которое будет регулярно выполнять операцию cvs up -d -P, например, каждый раз после обновления копии репозитория. Разумеется, файлы должны находиться в иерархии, доступной для публичного веб-доступа. Мы сознательно не будем обсуждать здесь процесс установки и конфигурации веб-сервера для этих целей. Для того, чтобы страницы сайта стали доступны для просмотра, необходимо выполнить команду &man.make.1; в основном каталоге модуля www. В результате будет создан комплект стандартных файлов *.html, подготовленных для просмотра веб-броузером. Обращаем ваше внимание, что для этого потребуется предварительно установить пакет textproc/docproj. Если у вас нет локальной копии репозитория, можно использовать CVSup для синхронизации копии веб-страниц. Пример конфигурации можно найти в файле /usr/share/examples/cvsup/www-supfile. Приведем его здесь: # # WWW module supfile for FreeBSD # *default host=cvsup3.de.FreeBSD.org *default base=/usr *default prefix=/usr/local *default release=cvs tag=. *default delete use-rel-suffix # If your network link is a T1 or faster, comment out the following line. *default compress # This collection retrieves the www/ tree of the FreeBSD repository www Использование пакета ftp/wget или иных инструментов для создания веб-зеркал не рекомендуется. Зеркала документации FreeBSD Поскольку многие веб-страницы ссылаются на документацию, хорошей идеей является поддержка зеркала документации FreeBSD совместно с прочими зеркалами. Надо отметить, что этот процесс не столь тривиален, как поддержка зеркала веб-страниц самих по себе. Для начала вы должны создать копию исходных текстов документации (как и во многих других случаях, для этого предпочтителен CVSup). Вот пример файла конфигурации: # # FreeBSD documentation supfile # *default host=cvsup3.de.FreeBSD.org *default base=/usr *default prefix=/usr/share *default release=cvs tag=. *default delete use-rel-suffix # If your network link is a T1 or faster, comment out the following line. #*default compress # This will retrieve the entire doc branch of the FreeBSD repository. # This includes the handbook, FAQ, and translations thereof. doc-all Затем, вам потребуется несколько пакетов. К счастью, специально для этого существует мета-порт textproc/docproj. Также, необходимо установить некоторые переменные окружения, например SGML_CATALOG_FILES, и переменные в файле /etc/make.conf, главным образом переменную DOC_LANG (используйте файл /usr/share/examples/make.conf как шаблон). После этого можно выдать команду make в главном каталоге документации (по умолчанию это /usr/share/doc). Как и прежде, эти каталоги должны быть доступны для вашего веб-сервера (проверьте, что ссылки ведут в нужные места). Процесс подготовки и построения документации, а также многие сопутствующие вопросы, подробно описан в документе fdp-primer. Прочтите этот документ, в особенности если у вас возникли проблемы со сборкой стандартного комплекта документации FreeBSD. XXX MAYBE THIS CAN BE LINKED FROM WITHIN - NOT USING AN ABSOLUTE URL XXX Как часто синхронизироваться? Каждое зеркало должно регулярно обновляться. Вам потребуется какой-то набор скриптов, выполняемых посредством &man.cron.8;. Поскольку каждый администратор, как правило, пишет такие скрипты сам и на свой лад, мы не можем выдать конкретных указаний. Общие же советы выглядят так: Создайте скрипт с командой, которая запустит нужное приложение для обновления зеркала. Рекомендуем использовать скрипт на языке обычного /bin/sh. Добавьте команд перенаправления вывода, чтобы записать диагностику работы в файл. Попробуйте, как ваш скрипт работает. По завершении проверьте логи. При помощи утилиты &man.crontab.1; добавьте ваш скрипт в таблицу регулярных заданий &man.crontab.5; соответствующего пользователя. Это должен быть пользователь, отличный от пользователя FTP-даемона, чтобы файлы в FTP-области без атрибута "чтение для всех" не были доступны анонимным FTP-пользователям. Данное свойство используется для тестирования перед выходом новых релизов, для того чтобы удостовериться, что все официальные зеркала содержат все необходимые файлы к моменту официального объявления релиза. Некоторые рекомендуемые установки частоты обновления: FTP-набор: раз в сутки репозиторий CVS: от раза в сутки до раза в час WWW-страницы: раз в сутки С какого сервера синхронизироваться Это важный вопрос, так что мы попытаемся пояснить, откуда берутся ответы. Для начала повторим еще несколько раз: никогда не синхронизируйтесь с ftp.FreeBSD.org . Организация системы зеркал Зеркала организуются по странам. Имена хостов всех официальных зеркал построены по принципу ftpN.CC.FreeBSD.org, где CC (country code) — домен верхнего уровня страны, где расположено зеркало, N — номер зеркала в данной стране. Этот же принцип применим к именам хостов cvsupN.CC.FreeBSD.org, wwwN.CC.FreeBSD.org и т.п. Кроме того, есть зеркала без доменной части, обозначающей страну. Все они имеют очень хорошие внешние каналы и обслуживают большое число одновременных соединений. Имя ftp.FreeBSD.org на самом деле указывает на две машины, одна из которых в настоящее время находится в Дании, а другая в США. Ни одна из этих машин НЕ является основным сайтом, и потому не должна использоваться для синхронизации. Масса документации для живых пользователей указывает на ftp.FreeBSD.org, так что автоматическим системам ведения зеркал следует выбирать другие источники синхронизации. Кроме того, существует иерархия зеркал в терминах их удаленности от центра, или слоях. Основные сайты могут быть описаны как Зеркала нулевого слоя. Зеркала, синхронизирующиеся по ним, считаются слоем 1, следующие — слоем 2 и т.д. Официальные сайты приглашаются на низкие слои, однако следует помнить, что чем меньше номер слоя, тем выше требования к зеркалу, как было описано в . Помимо того, доступ к зеркалам 1 слоя может быть ограничен; безусловно ограничен доступ к основным сайтам. Иерархия слоев не отражается в DNS и, вообще говоря, нигде (кроме мастер-сайтов) не документирована. Тем не менее, официальные зеркала с малыми (1-4, как правило) номерами обычно представляют первый слой. (Это грубая оценка, и ни в коем случае не правило). Так откуда же мне синхронизироваться? Главное — НЕ с ftp.FreeBSD.org. Короткий ответ: с зеркала, которое расположено недалеко от вас в терминах Интернет, и/или доступ к которому наилучший. Я хочу получить копию зеркала хоть откуда-нибудь! Если у вас нет каких-либо специальных предпочтений или требований, см. . Это означает: Посмотрите на список доступных зеркал в вашей стране. Вам может помочь База данных зеркал FreeBSD. Выберите те из них, с которыми вам работать быстрее всего (меньшее число промежуточных узлов и время отклика), и которые предоставляют нужные вам сервисы (такие как rsync или CVSup). Свяжитесь с администраторами выбранного сервера, опишите ваши запросы и уточните их правила. Сконфигурируйте ваше зеркало, как описывалось выше. Я поддерживаю официальное зеркало, какой сайт мне выбрать? В основном, правила, описанные в , применимы. Дополнительно можно убедиться, что выбранный сайт принадлежит низкому слою. Другие соображения относительно официальных зеркал описаны в . Мне нужен доступ к основным сайтам! При наличии достаточных причин вы можете получить доступ к одному из основных сайтов. Доступ к ним ограничен; существуют специальные правила их использования. Наличие у вас статуса официального зеркала, безусловно, является хорошим подспорьем. В противном случае убедитесь, что ваша страна действительно нуждается еще в одном зеркале. Если их уже три или более, сначала свяжитесь с администратором соответствующей зоны DNS (hostmaster@CC.FreeBSD.org) или напишите в &a.hubs;. Доступ к одному из мастер-сайтов или подходящему зеркалу 1 уровня вам помогут обеспечить те же, кто помогал вам получить статус официального зеркала. В случае неудачи свяжитесь с mirror-admin@FreeBSD.org и попросите помощи у них. Существует три основных сайта для синхронизации набора файлов FTP и один для репозитория CVS. Веб-страницы и документация хранятся в CVS, поэтому не имеют отдельных основных сайтов. ftp-master.FreeBSD.org Это основной сервер для синхронизации FTP набора. ftp-master.FreeBSD.org поддерживает доступ по rsync и CVSup. Использование этих протоколов описано в разделах и . Приветствуется предоставление зеркалами 1 уровня доступа к FTP-области по протоколу rsync. cvsup-master.FreeBSD.org Это основной сервер для синхронизации репозитория CVS. cvsup-master.FreeBSD.org обеспечивает доступ только по протоколу CVSup. Детали см. в . Для получения доступа к этому серверу вам нужно связаться с &a.cvsup-master;. Не забудьте сначала прочитать Правила доступа к центральному CVSup серверу FreeBSD! Подготовьте параметры авторизации, как описано здесь. Не забудьте, что в качестве имени сервера команде cvpasswd нужно указать freefall.FreeBSD.org, несмотря на то, что устанавливать соединение вы будете с cvsup-master.FreeBSD.org. Официальные зеркала Официальные зеркала обладают следующим свойствами: a) имеют запись в домене FreeBSD.org (обычно типа CNAME). b) присутствуют в списке официальных зеркал в Руководстве по FreeBSD и другой документации. На настоящий момент это все, что отличает их от прочих зеркал. Официальные зеркала не обязательно принадлежат к Первому уровню, однако, вряд ли можно найти зеркало уровня 1, не являющееся официальным. Отдельные требования к официальным зеркалам 1 уровня Описать требования для всех официальных зеркал не так просто, поскольку проект FreeBSD достаточно мягок в этом отношении. Несколько проще указать, что требуется от официальных зеркал уровня 1. Прочие официальные зеркала должны рассматривать этот список как настойчивые пожелания. Следующее относится в основном к набору файлов FTP, поскольку репозиторий CVS всегда должен зеркалироваться полностью, а веб-страницы представляют собой несколько особый случай. Зеркала 1 уровня должны: поддерживать полный список файлов предоставлять доступ для других зеркал обеспечивать доступ по протоколам FTP и RSYNC. Кроме того, администратор такого зеркала должен быть подписан на &a.hubs;. См. здесь для дополнительной информации о подписке. Администраторы зеркал, в особенности 1 уровня, должны очень внимательно следить за графиком релизов. Это поможет подготовиться к крупным всплескам нагрузки на зеркало, которые всегда происходят после очередного релиза. Кроме того, важно поддерживать актуальность зеркал (в особенности зеркал уровня 1). Если Зеркало1 не синхронизировалось в течение длительного времени, то зеркала следующего уровня будут синхронизироваться по устаревшей информации и т.д. Поддерживайте актуальность ваших зеркал! Как стать официальным зеркалом? Небезынтересный вопрос, в особенности если учитывать последствия становления официальным зеркалом, например, увеличившиеся счета за интернет от вашего провайдера (ведь нагрузка на ваш сервер неизбежно увеличится). Статус официального зеркала может быть ключевым требованием для доступа к основному сайту. Прежде чем отправлять заявку, убедитесь в необходимости дополнительного официального зеркала в вашем регионе. Справьтесь у администратора вашей зоны (hostmaster@CC.FreeBSD.org) или, в случае, если вам не отвечают, здесь: &a.hubs;. Собственно процедура такова: Обеспечьте работоспособность и актуальность зеркала (скорее всего, синхронизируясь не по основному сайту). Подпишитесь здесь на &a.hubs;. После успешного завершения предыдущих пунктов, напишите администратору DNS вашего региона (страны) и попросите его создать запись в зоне для вашего сайта. Почтовый адрес администратора hostmaster@CC.FreeBSD.org, где CC — код вашей страны (и суффикс домена верхнего уровня). Формат вашей записи в DNS описан в . Если для вашей страны пока не создано поддомена, свяжитесь с mirror-admin@FreeBSD.org или сначала напишите в &a.hubs;. Персона, помогавшая вам получить статус официального зеркала, должна послать письмо mirror-admin@FreeBSD.org, чтобы ваш сайт был включен в список официальных зеркал в Руководстве FreeBSD. Статистика некоторых зеркал Вот несколько ссылок на статистику использования зеркал Статистика FTP сайтов ftp2.FreeBSD.org - grisha@ispol.com - (загрузка канала) ftp.is.FreeBSD.org - hostmaster@is.FreeBSD.org - (загрузка канала) (FTP процессы) (HTTP процессы) ftp.cz.FreeBSD.org - cejkar@fit.vutbr.cz - (загрузка канала) (FTP процессы) (Rsync процессы) ftp2.ru.FreeBSD.org - mirror@macomnet.ru - (Bandwidth) (HTTP and FTP users) Статистика CVSup сайтов cvsup[23456].jp.FreeBSD.org - kuriyama@FreeBSD.org - (CVSup процессы) cvsup.cz.FreeBSD.org - cejkar@fit.vutbr.cz - (CVSup процессы)
diff --git a/ru_RU.KOI8-R/articles/mailing-list-faq/article.sgml b/ru_RU.KOI8-R/articles/mailing-list-faq/article.sgml index 5dfb605436..0ad9b33da0 100644 --- a/ru_RU.KOI8-R/articles/mailing-list-faq/article.sgml +++ b/ru_RU.KOI8-R/articles/mailing-list-faq/article.sgml @@ -1,538 +1,538 @@ %articles.ent; ]>
Часто задаваемые вопросы по спискам рассылки &os; The &os; Documentation Project $FreeBSD$ 2004 2005 The &os; Documentation Project Эта статья посвящена часто задаваемым вопросам (FAQ) по спискам рассылки &os;. Если вы хотите помочь поддерживать данный документ, напишите письмо в &a.doc;. Последняя версия данного документа доступна на WWW сервере &os;. Вы можете получить данную статью в - виде одного большого + виде одного большого HTML файла, используя HTTP протокол или в виде простого текста, форматов PostScript, PDF, и других с FTP сервера &os;. Возможно вы захотите Найти FAQ. Введение Цель этого документа ответить на часто задаваемые вопросы, касающиеся списков рассылки &os;. Хотя FAQ задумывались для снижения количества задаваемых повторяющихся вопросов, они стали восприниматься, как ценные источники информации. Этот документ - попытка представить консенсус всего сообщества, и поэтому он не может считаться официальным. Если вы найдете технические неточности в данном документе или у вас есть предложения по добавлению новых пунктов, пожалуйста отправьте PR или напишите в &a.doc;. Спасибо. Зачем вообще нужны списки рассылки по &os;? Списки рассылки по &os; служат, как первичное средство связи &os; сообщества, они покрывают множество различных тем. Кто пользуется этими списками рассылки? Это зависит от темы обсуждения каждого конкретного списка рассылки. Некоторые списки больше ориентированны на разработчиков, некоторые на всё сообщество &os; в целом. Список существующих на сегодняшний день списков рассылки доступен здесь. Доступны ли списки рассылки по &os; для каждого? Повторюсь, это зависит от характера обсуждаемых тем в каждом конкретном листе. Пожалуйста прочтите устав списка рассылки перед отправлением в него письма и соблюдайте его при каждом отправлении. Это будет полезно каждому получить больше опыта по работе со списками рассылки. Если после просмотра выше расположенного списка, вы до сих пор не знаете в какой список рассылки направить письмо, то вам наверняка подойдёт freebsd-questions (но прежде прочтите ниже). Заметьте, что для отправки письма в список рассылки необязательно быть подписанным на него. Это поможет легче присоединиться к сообществу &os; и способствует открытому обмену идей. Но, из-за небрежности некоторых людей некоторые списки проводят политику предварительного ручного просмотра сообщений от не подписанных пользователей, чтобы убедиться в их целесообразности. Как я могу подписаться? Вы можете использовать web интерфейс Mailman для подписки на любой из открытых списков рассылки. Как мне отписаться? Вы можете использовать вышеупомянутый интерфейс или следовать инструкциям, находящимся в конце каждого письма, отправленного в этот список рассылки. Пожалуйста, не посылайте письма с отказом от подписки в сами публичные списки. Во-первых, вы так не отпишитесь, а во-вторых, вызовете раздражение подписчиков, и вероятно получите неприятные высказывания в свой адрес. Это классическая ошибка при работе со списками рассылки; старайтесь не повторять её. Доступны ли архивы? Да. Архивы доступны здесь. Доступны ли списки рассылки в дайджест формате? Да. Посмотрите web интерфейс Mailman. Этикет списков рассылки Участие в любом списке рассылки, как и в любом другом сообществе требует общего базиса для общения. Пожалуйста, отправляйте только подходящие сообщения и следуйте общепринятым нормам этикета. Что я должен сделать перед отправлением письма? Вы уже сделали важный шаг, решив прочитать эту статью. Если вы новичок во &os;, то сначала ознакомьтесь с программным обеспечением и связанной с нею документацией, включающей множество - книг, - статьей. + книг и + статьей. Могут быть интересными: Часто задаваемые вопросы по &os; (FAQ), Руководство по &os; , и статьи Как работать со списком рассылки FreeBSD-questions с максимальной отдачей, Что такое BSD, и Пособие для новичков во &os;. Вы можете получить нелицеприятные высказывания в свой адрес, если зададите вопрос, ответ на который есть в приведённой выше документации. Это не потому что добровольцы, работающие над данным проектом очень плохие люди, а после многократного ответа на одни и те же вопросы - раздражение берёт своё. Это особенно справедливо, если уже существует и доступен ответ на вопрос. Не забывайте, что вся работа по улучшению &os; выполняется добровольцами, и что мы только люди. Что считается несоответствующим письмом? Письма должны соответствовать уставу списка рассылки. Избегайте личных оскорблений. Как хорошие жители сети, мы должны держать себя по высоким стандартам поведения. Спам не разрешён. Нарушители данного правила будут забаненны. Что считается хорошим этикетом при посылке писем в списки рассылки? Пожалуйста, составляйте строки длиной примерно в 75 символов, так так не каждый использует модную почтовую программу с графическим интерфейсом. Пожалуйста, обращайте внимание на тот факт, что пропускная способность ограничена. Не каждый читает почту через высокоскоростное соединение. Если вы отправляете содержимое какого-нибудь файла, например config.log или объёмную трассировку стека, то, пожалуйста, размещайте его на каком-нибудь веб-сайте и присылайте просто ссылку на на него. Помните, что такие сообщения будут заархивированны, и это просто добавит ненужные байты к архиву. Оформляйте ваше сообщение, чтобы оно было читабельно и ПОЖАЛУЙСТА, НЕ КРИЧИТЕ!!!!!. Не упускайте из виду эффект, которое производит плохо отформатированное письмо, причём не только в списках рассылки &os;. Ваше сообщение будет просмотрено другими людьми, и если оно плохо отформатировано, имеет множество ошибок и/или восклицательных знаков, то это создаст нехорошее впечатление о вас. Пожалуйста, используйте подходящий язык общения для - конкретного списка рассылки. + конкретного списка рассылки. Существует много не англоязычных рассылок. Мы понимаем, что для многих английский не родной язык и поэтому мы пытаемся сделать некие пособия. Считается плохим тоном критиковать людей не говорящих по-английски за лексические и грамматические ошибки. &os; имеет отличные продвижения в этом отношении. Пожалуйста, помогайте сохранять нам эту традицию. Пожалуйста, используйте совместимый со стандартами почтовый клиент (MUA). Много плохо отформатированных - сообщений исходят от + сообщений исходят от неправильно работающих или плохо сконфигурированных почтовых клиентов. Известно, что следующие почтовые программы могут посылать неправильно отформатированные сообщения без вашего ведома: - - + + cc:Mail &eudora; (старые версии) exmh µsoft; Exchange µsoft; Internet Mail µsoft; &outlook; &netscape; (старые версии) Как вы можете видеть, виновниками зачастую являются почтовые - программы из мира Microsoft. Если это вообще возможно, используйте - почтовую программу из &unix;. Если вы должны использовать почтовую - программу в среде Microsoft, удостоверьтесь в корректности ее - настроек. Постарайтесь не использовать MIME: - многие используют программы, которые не очень хорошо работают с - MIME. + программы из мира Microsoft. Если это вообще возможно, используйте + почтовую программу из &unix;. Если вы должны использовать почтовую + программу в среде Microsoft, удостоверьтесь в корректности ее + настроек. Постарайтесь не использовать MIME: + многие используют программы, которые не очень хорошо работают с + MIME. - Проверьте правильность настроек времени и временной зоны. Это - может выглядеть немножко глупо, потому что ваши сообщения все равно - будут доставляться, однако многие люди получают несколько сотен - сообщений в день. Зачастую они сортируют входящие сообщения по - теме и дате, и если ваше сообщение не будет предшествовать первому - ответу, то они могут предположить, что оно потерялось и даже не - взглянут на него. + Проверьте правильность настроек времени и временной зоны. Это + может выглядеть немножко глупо, потому что ваши сообщения все равно + будут доставляться, однако многие люди получают несколько сотен + сообщений в день. Зачастую они сортируют входящие сообщения по + теме и дате, и если ваше сообщение не будет предшествовать первому + ответу, то они могут предположить, что оно потерялось и даже не + взглянут на него. - Основной объем информации, который вы должны предоставить, представляет - собой вывод программ, таких, как &man.dmesg.8;, или консольные - сообщения, которые обычно появляются в файле - /var/log/messages. Не пытайтесь скопировать + Основной объем информации, который вы должны предоставить, представляет + собой вывод программ, таких, как &man.dmesg.8;, или консольные + сообщения, которые обычно появляются в файле + /var/log/messages. Не пытайтесь скопировать эту информацию, набрав ее снова; это действительно трудно, и здесь легко сделать ошибку. Чтобы послать содержимое файлов протоколов, сделайте копию файла и воспользуйтесь редактором для того, чтобы обрезать информацию, оставив только относящуюся к делу, либо скопируйте и вставьте текст в ваше сообщение. В случае вывода программ, таких, как dmesg, перенаправьте вывод в файл и - включите его в письмо. Например, + включите его в письмо. Например, &prompt.user; dmesg > /tmp/dmesg.out Данная команда перенаправит информацию в файл /tmp/dmesg.out. При использовании операций копирования и вставки - учтите, что некоторые такие операции отрицательно сказываются + учтите, что некоторые такие операции отрицательно сказываются на формате строк. Особенно это стоит учесть при посылке содержимого файлов Makefile, где tab является важным символом. Это - довольно часто встречающаяся проблема + довольно часто встречающаяся проблема в базе данных сообщений об ошибках GNATS. В Makefile символы tab меняются на пробелы, или раздражающие =3B escape последовательности. Каких правил этикета стоит придерживаться при ответе на уже существующее сообщение? Пожалуйста, включайте относящийся к теме текст из исходного письма. Сокращайте его до минимума, но не переусердствуйте. Любой, кто не читал исходное сообщение должен суметь понять о чём идёт речь. Это особенно важно для ответов, где исходное сообщение составляло сотни строчек. Отделяйте текст исходного сообщения от текста, добавляемого вами. Чаще всего строчки исходного сообщения предваряются > и пробелом. Отделяйте ваш текст от текста исходного сообщения пустыми строчками. Эти правила помогут сделать ваши сообщения более читабельными. Пожалуйста, убедитесь, что присваивания текста, который вы цитируйте корректны. Люди могут обидеться, если вы присвоите им слова, которые они не писали. Пожалуйста, не пишите ответ в начале. Это значит, что при ответе на сообщения, вставляйте ваши ответы в конец, после текста, копируемого из исходного сообщения. A: Потому что это не соответствует логическому ходу обсуждения. Q: Почему верхнее сообщение осуждает это? (Спасибо Рэнди Бушу (Randy Bush) за шутку.) Повторяющиеся темы в списках рассылки Участие в списках рассылки, как и участие в любом сообществе требует общего базиса для общения. Большое количество рассылок предполагают знание истории Проекта. В частности, существует несколько тем обсуждения, которые возникают у новичков. Обязанность каждого участника не создавать дискуссии на эти темы, тем самым помочь спискам рассылки не отрываться от обсуждаемых тем и обезопасить себя от разгорячённых бесед. Лучший способ предотвратить это - ознакомиться с архивами списков рассылки, чтобы понять, что происходило до этого. В этом случае, незаменимым окажется интерфейс поиска по спискам рассылки. (Если этот способ не принёс результатов, воспользуйтесь вашей любимой поисковой системой). Познакомившись с архивами, вы не только будете знать какие темы обсуждались до этого, а также узнаете какие тенденции общения существуют в данной рассылке, кто является участниками и какова конечная аудитория. Эти вещи довольно хорошо знать перед отправкой письма в любую рассылку, и это касается не только списков - рассылки &os;. + рассылки &os;. Нет сомнения, что архивы довольно объёмные и некоторые вопросы повторяются гораздо чаще чем другие, иногда в виде откликов (followups), где тема сообщения уже не соответствует новому положению дел. Тем не менее, старайтесь избегать повторяющихся тем и особенно тем, по которым сообщество никогда не придёт к единому мнению (bikesheeds). Что такое велосипедный навес ("Bikeshed")? В литературной нотации, велосипедный навес - это маленький внешний кожух, в который можно поместить один вид двухколёсного транспорта. Тем не менее, на языке &os; слово означает оскорбительный термин, который относится к любой часто повторяющейся дискуссии по определённой теме. Если более конкретно, то этот термин чаще всего используют для некой темы, которая никогда не достигнет консенсуса сообщества &os; и останется спорной. (Детали происхождения данного термина более подробно рассмотрены здесь). У вас должно иметься представление о данном понятии перед отправкой письма в любой список рассылки &os;. Bikeshed - это тема разговора, которая будет иметь тенденцию порождать немедленные мета-дискуссии и флэйм. Пожалуйста, помогайте сохранять списки рассылки настолько полезными для многих людей, насколько это возможно путём предотвращения bikesheed. Спасибо. Благодарности &a.grog; Первоначальный автор большинства материала по этикету списков рассылки, взятого из статьи Как работать со списком рассылки FreeBSD-questions с максимальной отдачей. &a.linimon; Создание черновой версии данного FAQ.
diff --git a/ru_RU.KOI8-R/articles/releng/article.sgml b/ru_RU.KOI8-R/articles/releng/article.sgml index 0a2e52651f..01b934e3a1 100644 --- a/ru_RU.KOI8-R/articles/releng/article.sgml +++ b/ru_RU.KOI8-R/articles/releng/article.sgml @@ -1,1092 +1,1101 @@ %articles.ent; The Release Engineering of Third Party Packages'> ]>
Подготовка релизов FreeBSD + Великобритания, 11 ноября 2001 --> Ноябрь 2001 BSDCon Europe - Murray + Murray - Stokely + Stokely - - Я участвовал в разработке продуктов на основе FreeBSD с - 1997 года в компаниях Walnut Creek CDROM, BSDi, а теперь Wind River - Systems. FreeBSD 4.4 была первым официальным релизом FreeBSD, в - выпуске которого я принимал значительное участие. - + + Я участвовал в разработке продуктов на основе FreeBSD с + 1997 года в компаниях Walnut Creek CDROM, BSDi, а теперь Wind River + Systems. FreeBSD 4.4 была первым официальным релизом FreeBSD, в + выпуске которого я принимал значительное участие. + - -
- murray@FreeBSD.org + +
+ murray@FreeBSD.org - -
- + +
+ $FreeBSD$ &tm-attrib.freebsd; &tm-attrib.cvsup; &tm-attrib.intel; &tm-attrib.xfree86; &tm-attrib.general; В этой статье описывается подход, который используется группой - подготовки релизов FreeBSD для создания качественных версий - Операционной Системы FreeBSD. В ней детально описывается методология, - используемая для официальных релизов FreeBSD и рассказывается об - инструментах, доступных тем, кто интересуется созданием - модифицированных релизов FreeBSD для тиражирования внутри организации - или в коммерческих целях. + подготовки релизов FreeBSD для создания качественных версий + Операционной Системы FreeBSD. В ней детально описывается методология, + используемая для официальных релизов FreeBSD и рассказывается об + инструментах, доступных тем, кто интересуется созданием + модифицированных релизов FreeBSD для тиражирования внутри организации + или в коммерческих целях. Введение Разработка FreeBSD представляет собой весьма открытый процесс. FreeBSD составляется в результате общих усилий тысяч людей по всему миру. Проект FreeBSD предоставляет анонимный публичный доступ по протоколу CVS[1], так что любой может получить доступ к журналу изменений, разницам (патчам) между ветками разработки и другим продвинутым возможностям, которые даёт строгое управление исходным кодом. Это сильно помогает в привлечении к FreeBSD всё большего количества талантливых разработчиков. Однако, и я думаю, что все со мной согласятся, наступит хаос, если доступ по записи будет открыт всем в Internet. Поэтому только избранная группа примерно из 300 человек имеет доступ по записи в CVS-хранилище. Эти коммиттеры[5] отвечают в целом за разработку FreeBSD. Выбираемая из самых заслуженных разработчиков группа правления[6] обеспечивает некоторый уровень управления проектом. Темп разработок, ведущихся во FreeBSD, оставляет мало времени на тщательную доводку системы до качества продуктивного релиза. Для решения этой проблемы разработка ведётся в два параллельных потока. Основной веткой разработки является HEAD, она же основная линия нашего дерева CVS, известная также под именем FreeBSD-CURRENT или, для краткости, -CURRENT. Поддерживается и более стабильная ветка, известная как FreeBSD-STABLE или, для краткости, -STABLE. Обе ветки находятся в основном CVS-хранилище в Калифорнии и реплицируются при помощи CVSup[2] на зеркала по всему миру. FreeBSD-CURRENT[7] является передним краем работ над FreeBSD, через который попадают все изменения в системе. FreeBSD-STABLE является веткой разработки, из которой создаются основные релизы. В эту ветку изменения попадают разными путями, и предполагается, что сначала они попали в FreeBSD-CURRENT, где были тщательно протестированы сообществом наших пользователей. В промежутке между релизами машинами Проекта FreeBSD, выделенными для построения системы, каждую ночь автоматически собираются снэпшоты, которые доступны для закачки по адресу ftp://stable.FreeBSD.org/. Общедоступность снэпшотов бинарных релизов, а также желание сообщества наших пользователей отслеживать работу над -STABLE при помощи CVSup и make world[7] помогает поддержать весьма хорошее качество FreeBSD-STABLE, даже до выполнения мероприятий проверки качества, предваряющих выпуск основных релизов. В процессе выпуска релиза пользователи постоянно присылают сообщения об ошибках и пожелания по расширению функциональности. Сообщения о проблемах попадают в нашу базу данных GNATS[8] по электронной почте, посредством утилиты &man.send-pr.1; или через Web-интерфейс, доступный по адресу . Кроме множества различных технических списков рассылки о FreeBSD, по адресу &a.qa; можно найти форум для обсуждения улучшений в процессе выпуска релизов. Для удовлетворения наших самых консервативно настроенных пользователей, начиная с FreeBSD 4.3, появились ветки для отдельных релизов. Эти ветки создаются вскоре после того, как выпускается окончательный релиз. После его выхода в ветку релиза помещаются только самые критичные исправления и добавления, касающиеся безопасности. Кроме обновлений исходных текстов посредством CVS, для систем веток RELENG_X_Y имеются и бинарные наборы патчей. В обсуждаются различные этапы процесса подготовки релиза вплоть до построения актуальной системы, а описывает сам процесс сборки. описывает, как базовый релиз может быть расширен третьими сторонами, а проясняет некоторые из уроков, полученных при выпуске релиза FreeBSD 4.4. Наконец, в описывается будущие направления работ. Процесс выпуска релиза Новые релизы FreeBSD выпускаются из ветки -STABLE с интервалом примерно в четыре месяца. Процесс выпуска релизов FreeBSD начинается за 45 дней до предполагаемой даты релиза с того, что ответственный за релиз посылает сообщение по электронной почте в адрес списков рассылки для разработчиков, чтобы напомнить последним о наличии всего лишь 15 дней на внесение новых изменений до момента заморозки кода. В этот период многие разработчики выполняют действия, известные как MFC-переносы. MFC означает Merge From CURRENT (перенос из CURRENT) и описывает процесс переноса протестированных изменений из нашего дерева разработки -CURRENT в наше дерево -STABLE. Просмотр кода За тридцать дней до предполагаемого релиза хранилище исходных - текстов переводится в режим стабилизации кода. В этот - период все изменения в дереве -STABLE должны подтверждаться &a.re;. - В этот 15-дневный период разрешены следующие типы изменений: + текстов переводится в режим стабилизации кода. В этот + период все изменения в дереве -STABLE должны подтверждаться &a.re;. + В этот 15-дневный период разрешены следующие типы изменений: - - Исправления ошибок. - - - - Обновление документации. - - - - Исправления любого характера, касающиеся безопасности. - - - - Незначительные исправления в драйверах устройств, такие, как, - например, добавление новых ID устройств. - - - - Любые другие изменения, которые одобряет группа подготовки - релиза, с учётом потенциального риска. - + + Исправления ошибок. + + + + Обновление документации. + + + + Исправления любого характера, касающиеся безопасности. + + + + Незначительные исправления в драйверах устройств, такие, как, + например, добавление новых ID устройств. + + + + Любые другие изменения, которые одобряет группа подготовки + релиза, с учётом потенциального риска. + После первых 15 дней стабилизации кода выпускается - предварительный релиз, предназначенный для широкого - тестирования, а код переводится в состояние заморозки, - когда становится гораздо труднее доказывать необходимость внесения - новых изменений в систему, если они не касаются исправления серьёзных - ошибок или информационной безопасности. Во время заморозки кода каждую - неделю выпускается не менее одной предварительной версии релиза, до тех - пор, пока не будет готов окончательный вариант релиза. В дни, - предшествующие выпуску окончательного релиза, группа его подготовки - работает в постоянном контакте со службой безопасности и людьми, - поддерживающими документацию и порты, чтобы обеспечить доступность всех - компонентов, необходимых для успешного выпуска релиза. + предварительный релиз, предназначенный для широкого + тестирования, а код переводится в состояние заморозки, + когда становится гораздо труднее доказывать необходимость внесения + новых изменений в систему, если они не касаются исправления серьёзных + ошибок или информационной безопасности. Во время заморозки кода каждую + неделю выпускается не менее одной предварительной версии релиза, до тех + пор, пока не будет готов окончательный вариант релиза. В дни, + предшествующие выпуску окончательного релиза, группа его подготовки + работает в постоянном контакте со службой безопасности и людьми, + поддерживающими документацию и порты, чтобы обеспечить доступность всех + компонентов, необходимых для успешного выпуска релиза. Контрольный список для проверки окончательного релиза После того, как для широкого тестирования было выпущено несколько - предварительных релизов и все основные проблемы были решены, может - начаться процесс шлифовки окончательного релиза. + предварительных релизов и все основные проблемы были решены, может + начаться процесс шлифовки окончательного релиза. - Создание ветки релиза - - Как сказано во вводной части, ветка - RELENG_X_Y - является сравнительно новым добавлением в нашей методологии - подготовки релизов. Первым шагом в создании этой ветки является - проверка того, что вы работаете с самой последней версией исходных - текстов RELENG_X, из - которой вы хотите создать новую ветку. - - /usr/src&prompt.root; cvs update -rRELENG_4 -P -d - - Следующим шагом является создание тэга точки - ответвления, чтобы диффы облегчили работу с началом ветки в CVS: - - /usr/src&prompt.root; cvs rtag -rRELENG_4 RELENG_4_8_BP src - - После этого создаётся тэг новой ветки по команде: - - /usr/src&prompt.root; cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src - - - Использование тэгов - RELENG_* разрешено - только менеджерам CVS и участникам группы по выпуску - релизов. - - - - Тэгом в понятии CVS - называют метку, которая идентифицирует исходный текст в некоторый - момент времени. Вводя тэг в дерево, мы обеспечиваем то, что в - будущем тот, кто строит релиз, всегда сможет воспользоваться тем же - самым кодом, что использовался нами для создания официальных - релизов Проекта FreeBSD. - - - - - - - - - Ветви разработки FreeBSD - - - - - - - - - - Ветка FreeBSD 3.x STABLE - - - - - - - - - - Ветка FreeBSD 4.x STABLE - - - - - - - - - - Ветка FreeBSD 5.x STABLE - - + Создание ветки релиза + + Как сказано во вводной части, ветка + RELENG_X_Y + является сравнительно новым добавлением в нашей методологии + подготовки релизов. Первым шагом в создании этой ветки является + проверка того, что вы работаете с самой последней версией исходных + текстов RELENG_X, из + которой вы хотите создать новую ветку. + + /usr/src&prompt.root; cvs update -rRELENG_4 -P -d + + Следующим шагом является создание тэга точки + ответвления, чтобы диффы облегчили работу с началом ветки в CVS: + + /usr/src&prompt.root; cvs rtag -rRELENG_4 RELENG_4_8_BP src + + После этого создаётся тэг новой ветки по команде: + + /usr/src&prompt.root; cvs rtag -b -rRELENG_4_8_BP RELENG_4_8 src + + + Использование тэгов + RELENG_* разрешено + только менеджерам CVS и участникам группы по выпуску + релизов. + + + + Тэгом в понятии CVS + называют метку, которая идентифицирует исходный текст в некоторый + момент времени. Вводя тэг в дерево, мы обеспечиваем то, что в + будущем тот, кто строит релиз, всегда сможет воспользоваться тем же + самым кодом, что использовался нами для создания официальных + релизов Проекта FreeBSD. + + + + + + + + + Ветви разработки FreeBSD + + + + + + + + + + Ветка FreeBSD 3.x STABLE + + + + + + + + + + Ветка FreeBSD 4.x STABLE + + + + + + + + + + Ветка FreeBSD 5.x STABLE + + + + + + + + + + Ветка FreeBSD 6.x STABLE + + - Увеличение номера версии - - Перед тем, как окончательный релиз будет помечен, построен и - выпущен, необходимо модифицировать следующие файлы, отразив в них - корректную версию FreeBSD: - - - - doc/ru_RU.KOI8-R/books/handbook/mirrors/chapter.sgml - - - - doc/en_US.ISO8859-1/books/porters-handbook/book.sgml - - - - doc/share/sgml/freebsd.ent - - - - src/Makefile.inc1 - - - - src/UPDATING - - - - src/gnu/usr.bin/groff/tmac/mdoc.local - - - - src/release/Makefile - - - - src/release/doc/en_US.ISO8859-1/share/sgml/release.dsl - - - - src/release/doc/share/examples/Makefile.relnotesng - - - - src/release/doc/share/sgml/release.ent - - - - src/share/examples/cvsup/standard-supfile - - - - src/sys/conf/newvers.sh - - - - src/sys/sys/param.h - - - - src/usr.sbin/pkg_install/add/main.c - - - - www/en/docs.sgml - - - - www/en/cgi/ports.cgi - - - - ports/Tools/scripts/release/config - - - - Новый релиз должен быть также отражён в файлах замечаний к релизу - и информации о замеченных ошибках (в ветке релиза), а файлы - соответствующим образом обрезаны (в ветке stable/current): - - - - src/release/doc/en_US.ISO8859-1/relnotes/common/new.sgml - - - - src/release/doc/en_US.ISO8859-1/errata/article.sgml - - - - Утилита sysinstall должна быть - обновлена и указывать количество доступных портов и объём дискового - пространства, требуемого для Коллекции Портов[4]. На данный момент эта - информация хранится в файле - src/release/sysinstall/dist.c. - - После построения релиза для оповещения мирового сообщества о - выпуске релиза необходимо обновить некоторые файлы. - - - - doc/share/images/articles/releng/branches-relengX.pic - - - - www/share/sgml/advisories.xml - - - - www/share/sgml/includes.release.sgml - - - - www/share/sgml/includes.release.xsl - - - - www/en/releases/* - - - - www/en/releng/index.sgml - - - - www/en/news/news.xml - - - - www/en/search/web.atoz - - - - src/share/misc/bsd-family-tree - - + Увеличение номера версии + + Перед тем, как окончательный релиз будет помечен, построен и + выпущен, необходимо модифицировать следующие файлы, отразив в них + корректную версию FreeBSD: + + + + doc/ru_RU.KOI8-R/books/handbook/mirrors/chapter.sgml + + + + doc/en_US.ISO8859-1/books/porters-handbook/book.sgml + + + + doc/share/sgml/freebsd.ent + + + + src/Makefile.inc1 + + + + src/UPDATING + + + + src/gnu/usr.bin/groff/tmac/mdoc.local + + + + src/release/Makefile + + + + src/release/doc/en_US.ISO8859-1/share/sgml/release.dsl + + + + src/release/doc/share/examples/Makefile.relnotesng + + + + src/release/doc/share/sgml/release.ent + + + + src/share/examples/cvsup/standard-supfile + + + + src/sys/conf/newvers.sh + + + + src/sys/sys/param.h + + + + src/usr.sbin/pkg_install/add/main.c + + + + www/en/docs.sgml + + + + www/en/cgi/ports.cgi + + + + ports/Tools/scripts/release/config + + + + Новый релиз должен быть также отражён в файлах замечаний к релизу + и информации о замеченных ошибках (в ветке релиза), а файлы + соответствующим образом обрезаны (в ветке stable/current): + + + + src/release/doc/en_US.ISO8859-1/relnotes/common/new.sgml + + + + src/release/doc/en_US.ISO8859-1/errata/article.sgml + + + + Утилита sysinstall должна быть + обновлена и указывать количество доступных портов и объём дискового + пространства, требуемого для Коллекции Портов[4]. На данный момент эта + информация хранится в файле + src/usr.sbin/sysinstall/dist.c. + + После построения релиза для оповещения мирового сообщества о + выпуске релиза необходимо обновить некоторые файлы. + + + + doc/share/images/articles/releng/branches-relengX.pic + + + + www/share/sgml/advisories.xml + + + + www/share/sgml/includes.release.sgml + + + + www/share/sgml/includes.release.xsl + + + + www/en/releases/* + + + + www/en/releng/index.sgml + + + + www/en/news/news.xml + + + + www/en/search/web.atoz + + + + src/share/misc/bsd-family-tree + + Подготовка новой старшей релиз ветки - (RELENG_<replaceable>X</replaceable>) + (RELENG_X) Когда новая старшая релиз ветка, такая как RELENG_6 - ответвляется из HEAD, некоторые дополнительные файлы должны + ответвляется из HEAD, некоторые дополнительные файлы должны быть обновлены перед тем, как релизы будут созданы из этой новой ветки. - src/share/examples/cvsup/stable-supfile + src/share/examples/cvsup/stable-supfile - когда применимо, должен быть обновлен, чтобы указывать на новую -STABLE ветку. - + - Создание тэгов релиза - - При готовности окончательного релиза следующая команда создаст - тэг RELENG_4_8_0_RELEASE. - - /usr/src&prompt.root; cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src - - Менеджеры документации и портов отвечают за внесение тэга в - соответствующие ветки с тэгом - RELEASE_4_8_0. - - Иногда в последний момент, уже после - создания последних тэгов может потребоваться внесение исправлений. - На практике это не является проблемой, так как CVS - позволяет выполнять манипуляции с тэгами по команде cvs - tag -d tagname filename. Очень - важно, чтобы все последние изменения были помечены соответствующим - тэгом, как часть релиза. Релизы FreeBSD должны быть всегда - повторяемыми. Локальные изменения в параметры окружения выпускающего - релиз недопустимы. + Создание тэгов релиза + + При готовности окончательного релиза следующая команда создаст + тэг RELENG_4_8_0_RELEASE. + + /usr/src&prompt.root; cvs rtag -rRELENG_4_8 RELENG_4_8_0_RELEASE src + + Менеджеры документации и портов отвечают за внесение тэга в + соответствующие ветки с тэгом + RELEASE_4_8_0. + + Иногда в последний момент, уже после + создания последних тэгов может потребоваться внесение исправлений. + На практике это не является проблемой, так как CVS + позволяет выполнять манипуляции с тэгами по команде cvs + tag -d tagname filename. Очень + важно, чтобы все последние изменения были помечены соответствующим + тэгом, как часть релиза. Релизы FreeBSD должны быть всегда + повторяемыми. Локальные изменения в параметры окружения выпускающего + релиз недопустимы. Построение релизов Релизы FreeBSD могут быть построены любым человеком, имеющим быстродействующую машину и доступ к хранилищу исходных текстов. (Это должен быть любой, так как мы предоставляем анонимный доступ к CVS! Обратитесь к Руководству для прояснения деталей.) Единственным особым требованием является наличие устройства &man.vn.4;. (В -CURRENT это устройство было заменено на новый драйвер дисков в памяти &man.md.4;.) Если устройство в вашем ядре не подгружено, то модуль ядра должен быть подгружен автоматически при выполнении команды &man.vnconfig.8; на этапе создания носителя для загрузки. Все инструменты, необходимые для построения релиза, доступны из хранилища CVS в каталоге src/release. Эти инструменты предоставляют единый метод построения релизов FreeBSD. Полный релиз может быть реально построен при помощи лишь одной команды, включая создание ISO-образов, подходящих для записи на CDROM, установочных дискет и установочного каталога FTP. Эта команда называется соответствующим образом, make release. <command>make release</command> Для успешного построения релиза вы должны сначала заполнить каталог - /usr/obj, запустив команду make - world или просто make buildworld. Цель, - выполняемая для построения релиза, требует корректного задания - нескольких переменных, используемых при его сборке: + /usr/obj, запустив команду make + world или просто make buildworld. Цель, + выполняемая для построения релиза, требует корректного задания + нескольких переменных, используемых при его сборке: - - CHROOTDIR - Каталог, используемый в среде с - изменённой корневой файловой системой при построении полного - релиза. - - - - BUILDNAME - Наименование строящегося - релиза. - - - - CVSROOT - Местонахождение - CVS-хранилища. - - - - RELEASETAG - Тэг CVS, соответствующий - релизу, который вы собираетесь строить. - + + CHROOTDIR - Каталог, используемый в среде с + изменённой корневой файловой системой при построении полного + релиза. + + + + BUILDNAME - Наименование строящегося + релиза. + + + + CVSROOT - Местонахождение + CVS-хранилища. + + + + RELEASETAG - Тэг CVS, соответствующий + релизу, который вы собираетесь строить. + Если у вас ещё нет доступа к локальному CVS-хранилищу, то вы можете - зеркалировать одно из них при помощи - CVSup. Поставляемый sup-файл, - /usr/share/examples/cvsup/cvs-supfile, может - служить хорошей отправной точкой для зеркалирования хранилища - CVS. + зеркалировать одно из них при помощи + CVSup. Поставляемый sup-файл, + /usr/share/examples/cvsup/cvs-supfile, может + служить хорошей отправной точкой для зеркалирования хранилища + CVS. Если RELEASETAG опущен, то релиз будет строиться - из ветки HEAD (известной как -CURRENT). Релизы, - строящиеся из этой ветки обычно называют снэпшотами - -CURRENT. + из ветки HEAD (известной как -CURRENT). Релизы, + строящиеся из этой ветки обычно называют снэпшотами + -CURRENT. Для настройки построения релиза существует много других переменных - Большинство из этих переменных описаны в начале файла - src/release/Makefile. Точная команда, служащая - для построения официального релиза FreeBSD 4.7 (x86) такова: + Большинство из этих переменных описаны в начале файла + src/release/Makefile. Точная команда, служащая + для построения официального релиза FreeBSD 4.7 (x86) такова: make release CHROOTDIR=/local3/release \ - BUILDNAME=4.7-RELEASE \ - CVSROOT=/host/cvs/usr/home/ncvs \ - RELEASETAG=RELENG_4_7_0_RELEASE + BUILDNAME=4.7-RELEASE \ + CVSROOT=/host/cvs/usr/home/ncvs \ + RELEASETAG=RELENG_4_7_0_RELEASE Makefile для релиза может быть разбит на - несколько различных шагов. + несколько различных шагов. - - Создание чистого системного окружения в отдельной иерархии - каталогов по команде make + + Создание чистого системного окружения в отдельной иерархии + каталогов по команде make installworld. - - - - Выгрузка из CVS чистой версии исходных текстов системы, - документации и портов в иерархию для построения релиза. - - - - Создание копии /etc и - /dev в окружении с изменённым корнем файловой - системы. - - - - Смена корневой файловой системы на иерархию построения релиза, - чтобы избежать влияния внешнего окружения на построение. - - - - Выполнение make world в окружении с - изменённой корневой файловой системой. - - - - Построение бинарных файлов для работы с Kerberos. - - - - Построение ядра GENERIC. - - - - Создание промежуточного дерева каталогов, где будут строиться - бинарные файлы и формироваться дистрибутивы. - - - - Построение и установка инструментов для работы с документацией, - необходимых для преобразования исходных текстов документации (SGML) - в формат HTML и текстовые документы, которые сопутствуют - релиз. - - - - Построение и установка актуальной документации (руководства - пользователей, учебники, замечания к релизу, перечень аппаратной - совместимости и так далее.) - - - - Построение свёрнутых бинарных файлов, - используемых на установочных дискетах. - - - - Подготовка дистрибутивных архивов бинарных файлов и исходных - текстов. - - - - Создание загрузочного носителя - и fixit-дискеты. - - - - Создание иерархии для установки при помощи FTP. - - - - (опционально) Создание образов ISO для - носителей CDROM/DVD. - + + + + Выгрузка из CVS чистой версии исходных текстов системы, + документации и портов в иерархию для построения релиза. + + + + Создание копии /etc и + /dev в окружении с изменённым корнем файловой + системы. + + + + Смена корневой файловой системы на иерархию построения релиза, + чтобы избежать влияния внешнего окружения на построение. + + + + Выполнение make world в окружении с + изменённой корневой файловой системой. + + + + Построение бинарных файлов для работы с Kerberos. + + + + Построение ядра GENERIC. + + + + Создание промежуточного дерева каталогов, где будут строиться + бинарные файлы и формироваться дистрибутивы. + + + + Построение и установка инструментов для работы с документацией, + необходимых для преобразования исходных текстов документации (SGML) + в формат HTML и текстовые документы, которые сопутствуют + релиз. + + + + Построение и установка актуальной документации (руководства + пользователей, учебники, замечания к релизу, перечень аппаратной + совместимости и так далее.) + + + + Построение свёрнутых бинарных файлов, + используемых на установочных дискетах. + + + + Подготовка дистрибутивных архивов бинарных файлов и исходных + текстов. + + + + Создание загрузочного носителя + и fixit-дискеты. + + + + Создание иерархии для установки при помощи FTP. + + + + (опционально) Создание образов ISO для + носителей CDROM/DVD. + Для получения более полной информации об инфраструктуре построения - релизов, пожалуйста, обратитесь к справочной странице - по &man.release.7;. + релизов, пожалуйста, обратитесь к справочной странице + по &man.release.7;. Построение <application>&xfree86;</application> &xfree86; является важным компонентом - для многих пользователей настольных систем. До выхода FreeBSD - 4.6-RELEASE в релизах по умолчанию использовалась &xfree86; - 3.X. Самым простым способом построения этих - версий является использование скрипта - src/release/scripts/X11/build_x.sh. Он требует, - чтобы на хост, выполняющий построение, уже были установлены &xfree86; и - Tcl/Tk. После компиляции необходимых X-серверов, скрипт преобразует - все файлы в архивные, которые &man.sysinstall.8; ожидает найти в - каталоге XF86336 на установочном носителе. + для многих пользователей настольных систем. До выхода FreeBSD + 4.6-RELEASE в релизах по умолчанию использовалась &xfree86; + 3.X. Самым простым способом построения этих + версий является использование скрипта + src/release/scripts/X11/build_x.sh. Он требует, + чтобы на хост, выполняющий построение, уже были установлены &xfree86; и + Tcl/Tk. После компиляции необходимых X-серверов, скрипт преобразует + все файлы в архивные, которые &man.sysinstall.8; ожидает найти в + каталоге XF86336 на установочном носителе. Начиная с FreeBSD 4.6-RELEASE, &man.sysinstall.8; по умолчанию - устанавливает &xfree86; 4.X, как набор - обычных пакаджей. Это могут быть как пакаджи, созданные - в процессе работы кластера построения портов, так и пакаджи, - построенные из соответствующим образом помеченного дерева - портов. + устанавливает &xfree86; 4.X, как набор + обычных пакаджей. Это могут быть как пакаджи, созданные + в процессе работы кластера построения портов, так и пакаджи, + построенные из соответствующим образом помеченного дерева + портов. Начиная с FreeBSD 5.3-RELEASE, &man.sysinstall.8; по умолчанию - устанавливает пакеты &xorg; взамен пакетов &xfree86;. + устанавливает пакеты &xorg; взамен пакетов &xfree86;. - Важно, чтобы из файла /etc/make.conf были - удалены все установки, специфичные для конкретного хоста. К примеру, - будет глупо распространять бинарные файлы, построенные на системе с - переменной CPUTYPE, указывающей на определённый - тип процессора. + Важно, чтобы из файла /etc/make.conf были + удалены все установки, специфичные для конкретного хоста. К примеру, + будет глупо распространять бинарные файлы, построенные на системе с + переменной CPUTYPE, указывающей на определённый + тип процессора. Программное обеспечение третьих лиц (<quote>ports</quote>) Коллекция портов - FreeBSD содержит более &os.numports; программных пакетов - сторонних разработчиков, которые доступны для FreeBSD. За поддержку - целостности дерева портов, которое может использоваться для создания - бинарных пакаджей, поставляемых с официальными релизами FreeBSD, - отвечает &a.portmgr;. + FreeBSD содержит более &os.numports; программных пакетов + сторонних разработчиков, которые доступны для FreeBSD. За поддержку + целостности дерева портов, которое может использоваться для создания + бинарных пакаджей, поставляемых с официальными релизами FreeBSD, + отвечает &a.portmgr;. Рассмотрение работ с нашей коллекцией пакетов сторонних - разработчиков при подготовке релизов выходит за рамки этого - документа. Этот вопрос глубоко рассмотрен в отдельной - статье, &art.re.pkgs;. + разработчиков при подготовке релизов выходит за рамки этого + документа. Этот вопрос глубоко рассмотрен в отдельной + статье, &art.re.pkgs;. ISO с релизами Начиная с FreeBSD 4.4, Проект FreeBSD принял решение распространять - все четыре образа ISO, ранее продаваемые через - BSDi/Wind River Systems/FreeBSD Mall как - официальные дистрибутивы на CDROM. Каждый из четырёх - дисков должен содержать файл README.TXT, - описывающий содержимое диска, файл CDROM.INF, в - котором находятся мета-данные о диске для того, чтобы - &man.sysinstall.8; мог проверять и использовать содержимое, а также - файл filename.txt, содержащий перечень содержимого - на диске. Этот перечень может быть создан простой - командой: + все четыре образа ISO, ранее продаваемые через + BSDi/Wind River Systems/FreeBSD Mall как + официальные дистрибутивы на CDROM. Каждый из четырёх + дисков должен содержать файл README.TXT, + описывающий содержимое диска, файл CDROM.INF, в + котором находятся мета-данные о диске для того, чтобы + &man.sysinstall.8; мог проверять и использовать содержимое, а также + файл filename.txt, содержащий перечень содержимого + на диске. Этот перечень может быть создан простой + командой: /stage/cdrom&prompt.root; find . -type f | sed -e 's/^\.\///' | sort > filename.txt Специфичные требования для каждого CD описываются ниже. - Диск 1 - - Первый диск практически полностью создаётся командой - make release. Единственным изменением, которое - нужно внести в каталог disc1, является - добавление подкаталогов tools и &xfree86;, а также перенос максимально - возможного количества программных пакетов сторонних разработчиков, - которые поместятся на диск. Каталог tools - содержит программное обеспечение, позволяющее пользователям создавать - установочные дискеты из других операционных систем. Этот диск нужно - сделать загрузочным, чтобы пользователям современных ПК не нужно было - создавать установочные дискеты. - - Если предоставляется другая версия &xfree86;, до должны быть - обновлены утилита &man.sysinstall.8;, отражающая новое - местоположение, и инструкции по установке. Соответствующий код - находится в каталоге src/release/sysinstall в - ветке -STABLE или в src/usr.sbin/sysinstall в - ветке -CURRENT. Должны быть обновлены конкретно файлы - dist.c, menus.c и - config.c. + Диск 1 + + Первый диск практически полностью создаётся командой + make release. Единственным изменением, которое + нужно внести в каталог disc1, является + добавление подкаталогов tools и &xfree86;, а также перенос максимально + возможного количества программных пакетов сторонних разработчиков, + которые поместятся на диск. Каталог tools + содержит программное обеспечение, позволяющее пользователям создавать + установочные дискеты из других операционных систем. Этот диск нужно + сделать загрузочным, чтобы пользователям современных ПК не нужно было + создавать установочные дискеты. + + Если предоставляется другая версия &xfree86;, до должны быть + обновлены утилита &man.sysinstall.8;, отражающая новое + местоположение, и инструкции по установке. Соответствующий код + находится в каталоге src/usr.sbin/sysinstall. + Должны быть обновлены конкретно файлы + dist.c, menus.c и + config.c. - Диск 2 - - Второй диск также в основном создаётся по команде make - release. Он содержит живую файловую - систему, которую можно использовать из &man.sysinstall.8; для - исправления процесса установки FreeBSD. Этот диск должен быть - загрузочным и содержать также упакованную копию хранилища CVS в - каталоге CVSROOT и демонстрационные версии - коммерческого программного обеспечения в каталоге - commerce. + Диск 2 + + Второй диск также в основном создаётся по команде make + release. Он содержит живую файловую + систему, которую можно использовать из &man.sysinstall.8; для + исправления процесса установки FreeBSD. Этот диск должен быть + загрузочным и содержать также упакованную копию хранилища CVS в + каталоге CVSROOT и демонстрационные версии + коммерческого программного обеспечения в каталоге + commerce. - Диски 3 и 4 + Диски 3 и 4 - Оставшиеся два диска содержат дополнительные программные пакеты - для FreeBSD. Они должны быть объединены в группы (кластеры), чтобы - отдельный пакет и все его зависимости находились - на одном и том же диске. Дополнительная информация о создании этих - дисков находится в статье &art.re.pkgs;. + Оставшиеся два диска содержат дополнительные программные пакеты + для FreeBSD. Они должны быть объединены в группы (кластеры), чтобы + отдельный пакет и все его зависимости находились + на одном и том же диске. Дополнительная информация о создании этих + дисков находится в статье &art.re.pkgs;. - Поддержка нескольких дисков + Поддержка нескольких дисков - Sysinstall поддерживает установку + Sysinstall поддерживает установку пакетов с нескольких дисков. Для это нужно, чтобы на каждом диске был файл INDEX, содержащий названия всех пакетов со всех дисков, с дополнительным полем, указывающем на каком диске содержится данный конкретный пакет. Также, на каждом диске, в файле cdrom.inf должна быть указана переменная CD_VOLUME для того, чтобы sysinstall мог определить какой этой диск. Когда пользователь будет пытаться установить пакет, которого нет на текущем диске, sysinstall выдаст запрос на вставку соответствующего диска. Распространение Серверы FTP После того, как релиз был тщательно протестирован и подготовлен к - распространению, должен быть обновлён главный FTP-сервер. Все - официальные общедоступные серверы FTP-серверы FreeBSD являются - зеркалами главного сервера, открытого только другим серверам FTP. Этот - сервер известен под именем ftp-master. Когда релиз - готов, на сервере ftp-master должны быть изменены - следующие строки: + распространению, должен быть обновлён главный FTP-сервер. Все + официальные общедоступные серверы FTP-серверы FreeBSD являются + зеркалами главного сервера, открытого только другим серверам FTP. Этот + сервер известен под именем ftp-master. Когда релиз + готов, на сервере ftp-master должны быть изменены + следующие строки: - - /pub/FreeBSD/releases/arch/X.Y-RELEASE/ - - - Установочный каталог FTP, получаемый по команде make - release. - - - - - /pub/FreeBSD/ports/arch/packages-X.Y-release/ - - - Полный комплект построенных пакаджей для этого релиза. - - - - - /pub/FreeBSD/releases/arch/X.Y-RELEASE/tools - - - Символическая ссылка на - ../../../tools. - - - - - /pub/FreeBSD/releases/arch/X.Y-RELEASE/packages - - - Символическая ссылка на - ../../../ports/arch/packages-X.Y-release. - - - - - /pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso - - - ISO-образы. Здесь * это + + /pub/FreeBSD/releases/arch/X.Y-RELEASE/ + + + Установочный каталог FTP, получаемый по команде make + release. + + + + + /pub/FreeBSD/ports/arch/packages-X.Y-release/ + + + Полный комплект построенных пакаджей для этого релиза. + + + + + /pub/FreeBSD/releases/arch/X.Y-RELEASE/tools + + + Символическая ссылка на + ../../../tools. + + + + + /pub/FreeBSD/releases/arch/X.Y-RELEASE/packages + + + Символическая ссылка на + ../../../ports/arch/packages-X.Y-release. + + + + + /pub/FreeBSD/releases/arch/ISO-IMAGES/X.Y/X.Y-RELEASE-arch-*.iso + + + ISO-образы. Здесь * это disc1, disc2 и так - далее. Только если здесь есть disc1 и - альтернативный первый установочный CD (например, обрезанная - установка без оконной системы), то здесь может быть также - и mini. - - + далее. Только если здесь есть disc1 и + альтернативный первый установочный CD (например, обрезанная + установка без оконной системы), то здесь может быть также + и mini. + + Для получения дополнительной информации о системе зеркальных - FTP-серверов FreeBSD, пожалуйста, прочтите статью о Зеркалировании FreeBSD. + FTP-серверов FreeBSD, пожалуйста, прочтите статью о Зеркалировании FreeBSD. Может пройти от нескольких часов до двух дней между тем, как - обновится ftp-master, и на основной массе FTP-серверов - 1-го уровня появится новое программное обеспечение, в зависимости от - того, в тоже самое ли время пакадж был загружен. Обязательно, чтобы - выпускающие релиз координировали свои действия с &a.mirror-announce; - до того, как объявлять об общедоступности нового программного - обеспечения с серверов FTP. В идеальном случае набора пакаджей к - релизу должен быть загружен по крайней мере за четыре дня до момента - выпуска релиза. Релиз должен быть загружен в промежутке от 24 до 48 - часов до момента выхода запланированного релиза с выключенными - полномочиями other. Это позволит зеркалирующим серверам - сгрузить его, но никто не сможет получить его с зеркальных серверов. - В момент выхода релиза должно быть послано сообщение в адрес - &a.mirror-announce;, говорящее о том, что релиз выпущен и наступило - время для открытия доступа на зеркальных серверах. Обязательно - вместе со временем укажите и часовой пояс, например, относительно - GMT. + обновится ftp-master, и на основной массе FTP-серверов + 1-го уровня появится новое программное обеспечение, в зависимости от + того, в тоже самое ли время пакадж был загружен. Обязательно, чтобы + выпускающие релиз координировали свои действия с &a.mirror-announce; + до того, как объявлять об общедоступности нового программного + обеспечения с серверов FTP. В идеальном случае набора пакаджей к + релизу должен быть загружен по крайней мере за четыре дня до момента + выпуска релиза. Релиз должен быть загружен в промежутке от 24 до 48 + часов до момента выхода запланированного релиза с выключенными + полномочиями other. Это позволит зеркалирующим серверам + сгрузить его, но никто не сможет получить его с зеркальных серверов. + В момент выхода релиза должно быть послано сообщение в адрес + &a.mirror-announce;, говорящее о том, что релиз выпущен и наступило + время для открытия доступа на зеркальных серверах. Обязательно + вместе со временем укажите и часовой пояс, например, относительно + GMT. Тиражирование CD-ROM Вскоре появится: Советы по передаче ISO-образов FreeBSD на - тиражирование и применяемые меры по контролю качества. + тиражирование и применяемые меры по контролю качества. Расширяемость Хотя FreeBSD представляет собой законченную операционную систему, ничего не заставляет вас использовать систему только в том виде, который приготовлен нами для распространения. Мы попытались спроектировать систему максимально расширяемой, чтобы она могла выполнять роль платформы, на основе которой можно строить другие коммерческие продукты. Единственным правилом, которое мы налагаем, является настоятельная рекомендация документировать улучшения, вносимые вами в дистрибутив FreeBSD с нетривиальными изменениями! Сообщество FreeBSD может помогать только пользователям того программного обеспечения, которое распространяем мы. Мы определённо приветствуем улучшения в форме, например, инструментов установки и администрирования, но не можем отвечать на вопросы о них. Создание модифицированных загрузочных дискет Во многих местах имеются сложные условия, которые требуют - размещения дополнительных модулей ядра или пользовательских - инструментов на установочные дискеты. Быстрым и - неаккуратным способом сделать это является изменение - промежуточного каталога в существующей иерархии при выполнении - make release: + размещения дополнительных модулей ядра или пользовательских + инструментов на установочные дискеты. Быстрым и + неаккуратным способом сделать это является изменение + промежуточного каталога в существующей иерархии при выполнении + make release: - - Примените патчи или добавьте дополнительные файлы в каталог - построения релиза с изменённых корнем файловой системы. - - - - rm - ${CHROOTDIR}/usr/obj/usr/src/release/release.[59] - - - - перестройте &man.sysinstall.8;, ядро и остальные части системы, - которые коснулись ваши изменения. - - - - chroot ${CHROOTDIR} ./mk floppies - + + Примените патчи или добавьте дополнительные файлы в каталог + построения релиза с изменённых корнем файловой системы. + + + + rm + ${CHROOTDIR}/usr/obj/usr/src/release/release.[59] + + + + перестройте &man.sysinstall.8;, ядро и остальные части системы, + которые коснулись ваши изменения. + + + + chroot ${CHROOTDIR} ./mk floppies + Дискеты нового релиза будут находиться в - ${CHROOTDIR}/R/stage/floppies. + ${CHROOTDIR}/R/stage/floppies. - Либо может быть вызвана цель - boot.flp построения или скрипт создания файловой - системы, src/release/scripts/doFS.sh, которые - может быть вызван напрямую. + Либо может быть вызвана цель + boot.flp построения или скрипт создания файловой + системы, src/release/scripts/doFS.sh, которые + может быть вызван напрямую. Локальные патчи могут быть также приложены к построению релиза при - помощи задания переменной LOCAL_PATCH при выполнении - make release. + помощи задания переменной LOCAL_PATCH при выполнении + make release. Скрипты <command>sysinstall</command> Инструмент установки и настройки системы FreeBSD, - &man.sysinstall.8;, может работать по сценарию, полезному для - автоматизированной установке в больших компаниях. Эта функциональность - может использоваться совместно с технологией &intel; PXE[12] для - первоначальной установки систем из сети, или с модифицированными - загрузочными дискетами со скриптами sysinstall. Пример скрипта для - sysinstall доступен в дереве CVS в виде файла - src/release/sysinstall/install.cfg. + &man.sysinstall.8;, может работать по сценарию, полезному для + автоматизированной установке в больших компаниях. Эта функциональность + может использоваться совместно с технологией &intel; PXE[12] для + первоначальной установки систем из сети, или с модифицированными + загрузочными дискетами со скриптами sysinstall. Пример скрипта для + sysinstall доступен в дереве CVS в виде файла + src/release/sysinstall/install.cfg. Уроки, извлечённые из FreeBSD 4.4 Формально процесс подготовки релиза для 4.4 начался 1 августа 2001 года. После этой даты все без исключения изменения в ветке RELENG_4 FreeBSD подтверждались &a.re;. Первый предварительный релиз для архитектуры x86 был выпущен 16 августа, за ним выходило ещё 4 предварительных релиза, и всё закончилось 18 августа выпуском окончательного релиза. Руководитель службы безопасности очень плотно занимался процессом выпуска в последнюю неделю, так как в предыдущих предварительных релизах были найдены проблемы, касающиеся информационной безопасности. Чуть более чем за месяц в адрес &a.re; поступило более 500 писем. Сообщество наших пользователей весьма чётко показало, что безопасность и стабильность релиза FreeBSD не должна приноситься в жертву любым назначенным срокам окончания работ или планируемым датам выхода релиза. Проект FreeBSD за время своего существования значительно вырос, и никогда ранее необходимость в стандартизации процедур подготовки релизов не стояла так остро. Это стало ещё более важно, когда FreeBSD была перенесена на новые аппаратные платформы. Направления будущих работ Нашим работам по подготовке релизов жизненно важно расти вместе с увеличением количества пользователей системы. Вместе с этим мы очень плотно работаем над документированием действий, выполняемых при выпуске релизов. - Параллелизм - некоторые этапы построения - релиза на самом деле выполнять параллельно - затруднительно. Большинство выполняемых задач весьма - интенсивно работают с I/O, так что для ускорения процесса - make release наличие нескольких высокоскоростных - дисков гораздо более важно, чем использование нескольких процессоров. - Если для различных иерархий в &man.chroot.2;-окружении используется - несколько дисков, то извлечение из CVS деревьев - ports и doc может - выполняться одновременно с командой make world на - другом диске. Использование RAID-решений - (аппаратных или программных) может значительно сократить общее время - построения. + Параллелизм - некоторые этапы построения + релиза на самом деле выполнять параллельно + затруднительно. Большинство выполняемых задач весьма + интенсивно работают с I/O, так что для ускорения процесса + make release наличие нескольких высокоскоростных + дисков гораздо более важно, чем использование нескольких процессоров. + Если для различных иерархий в &man.chroot.2;-окружении используется + несколько дисков, то извлечение из CVS деревьев + ports и doc может + выполняться одновременно с командой make world на + другом диске. Использование RAID-решений + (аппаратных или программных) может значительно сократить общее время + построения. - Кроссплатформенное построение - релизов - Построить релиз для IA-64 или Alpha на - x86-оборудовании? make TARGET=ia64 release. + Кроссплатформенное построение + релизов - Построить релиз для IA-64 или Alpha на + x86-оборудовании? make TARGET=ia64 release. - Тестирование - Нам нужна улучшенная - автоматизированная система тестирования корректности для - FreeBSD. + Тестирование - Нам нужна улучшенная + автоматизированная система тестирования корректности для + FreeBSD. - Инструменты установки - Наша программа - установки давно пережила свой век. В разработке находятся несколько - проектов, которые должны дать улучшенную технологию установки. + Инструменты установки - Наша программа + установки давно пережила свой век. В разработке находятся несколько + проектов, которые должны дать улучшенную технологию установки. Одним из таких проектов был libh, целью которого было создание новой интеллектуальной технологии работы с пакаджами и программы установки с GUI. Благодарности Я рад поблагодарить Джордана Хаббарда (Jordan Hubbard) за то, что он дал мне возможность взять под свою ответственность некоторые части процесса подготовки релиза FreeBSD 4.4, а также за все годы его работы, сделавшие FreeBSD такой, какой она является сейчас. Конечно, релиз не был бы возможен без той работы, которую проделали &a.asami;, &a.steve;, &a.bmah;, &a.nik;, &a.obrien;, &a.kris;, &a.jhb; и остальные члены сообщества разработчиков FreeBSD. Я также рад выразить благодарность &a.rgrimes; и &a.phk;, а также остальным, работавшим над инструментами подготовки релизов в первые годы существования FreeBSD. Эта статья была также написана под впечатлением документации по подготовке релизов от CSRG[13], NetBSD Project[10] и замечаний Джона Балдвина (John Baldwin) по предлагаемому процессу подготовки релизов[11]. Справочная литература [1] CVS - Concurrent Versions System [2] CVSup - The CVS-Optimized General Purpose Network File Distribution System [3] [4] Коллекция портов FreeBSD [5] Коммиттеры FreeBSD [6] Правление FreeBSD [7] Руководство FreeBSD [8] GNATS: The GNU Bug Tracking System [9] Статистика FreeBSD PR [10] NetBSD Developer Documentation: Release Engineering [11] John Baldwin's FreeBSD Release Engineering Proposal [12] PXE Jumpstart Guide [13] Marshall Kirk McKusick, Michael J. Karels, and Keith Bostic: The Release Engineering of 4.3BSD
diff --git a/ru_RU.KOI8-R/articles/version-guide/article.sgml b/ru_RU.KOI8-R/articles/version-guide/article.sgml index f04fbc45f8..2e2c4d6350 100644 --- a/ru_RU.KOI8-R/articles/version-guide/article.sgml +++ b/ru_RU.KOI8-R/articles/version-guide/article.sgml @@ -1,401 +1,401 @@ %articles.ent; ]>
Выбор подходящей для вас версии FreeBSD - + The FreeBSD Documentation Project - + $FreeBSD$ - + &tm-attrib.freebsd; - + 2005 The FreeBSD Documentation Project - + Итак, вы решили установить &os;. Добро пожаловать! Этот документ написан для того, чтобы помочь вам в выборе версии для установки. Вводная информация Чтобы решить какая версия &os; больше всего подходит для ваших нужд, важно понимать несколько концепций, касающихся наших процессов разработки и подготовки релизов (Release Engineering, RE). &os; разрабатывается большой группой людей, являющихся почти полностью добровольцами. Исходный код ядра, самых распространённых библиотек и утилит поддерживается в системе контроля исходного кода (source control system) и доступен широкой публике для скачивания в любое время. Отдельно, скомпилированные версии (бинарники) доступны на рекуррентной основе. Некоторые из этих двоичных версий проходят широкое тестирование и затем обозначаются, как release. Релизы Имена Релизов строятся из старшего номера версии и младшего номера версии. Цель старшего релиза - ввести новые возможности. Где необходимо, возможно нужно убрать совместимость с предыдущими старшими релизами, чтобы улучшить состояние &os;, или, иногда убрать возможности, которые больше невозможно (или не нужно) поддерживать. Цель младшего релиза - в основном исправление ошибок и улучшение производительности и стабильности. Поддержание совместимости между двумя младшими релизами приоритетно. Иногда новые возможности могут быть добавлены в младший релиз, когда видно, что другие цели не будут нарушены. Тем не менее, помните, что релиз - это просто снэпшот дерева исходного кода в определённый момент времени, которому присваивается конкретное имя (тэг). (К примеру, тэг во время подготовки релиза присвоенный релизу 5.4 был - RELENG_5_4_RELEASE). Разработка всегда продолжается + RELENG_5_4_0_RELEASE). Разработка всегда продолжается в так называемом тэге HEAD. Ветки Во время каждого релиза создается ветка (к примеру, RELENG_5_4). Исходные файлы, названные - RELENG_5_4_RELEASE изменяться никогда не будут, те + RELENG_5_4_0_RELEASE изменяться никогда не будут, те которые в RELENG_5_4 изменяться могут путём принятия изменений из HEAD, таких как исправления в безопасности и другие ошибки. Во время жизни каждого старшего релиза создаётся тэг (к примеру, RELENG_5). В дополнение к исправлениям в безопасности и исправлениям других ошибок, новые изменения могут быть приняты из HEAD, и таким образом составят изменения для следующего младшего релиза в последовательности. <firstterm>STABLE</firstterm> против <firstterm>CURRENT</firstterm> Во время жизни каждого старшего релиза, отдельная ветка может также называться STABLE. Это означает, что проект &os; считает, что ветвь имеет достаточно доказанную стабильность для использования широким кругом пользователей. Ветви, которые нуждаются в дальнейшем тестировании перед тем, как стать в значительной степени принятой называются CURRENT. Проект &os; ни внутри, ни вне себя не может гарантировать, что программное обеспечение, которое оно выпускает является достаточно стабильным для любой данной системы. Только каждый индивидуальный пользователь может сделать такое решение. Пожалуйста, помните, что Проект в основном состоит из добровольцев и не может предлагать любой вид гарантии пригодности. <firstterm>Порты</firstterm> против <firstterm>Пакетов</firstterm> Отдельно от файлов, распространяемых вышеуказанно, &os; поддерживает тысячи приложений, которые разрабатываются третьими лицами, вне самого проекта. (Сюда включены оконные системы, интернет браузеры, почтовые программы, офисные пакеты, и так далее) В общем, сам проект не разрабатывает это программное обеспечение, только инфраструктуру, позволяющую установить эти программы (называется Коллекция портов). Приложения могут быть установлены либо из исходников, если условия лицензии позволяют такое распространение (они называются порты), либо в виде скомпилированных двоичных файлов, если разрешено (они называются пакеты). Планирование релизов в прошлом Во время разработки и выпуска &os; 5.X было получено много - уроков, которые стали ясны только ретроспективно. Цели серии 5.X + уроков, которые стали ясны только ретроспективно. Цели серии 5.X были очень мощными и включали: Обеспечить поддержку машин с симметричной мультипроцессорностью (Symmetric MultiProcessing, SMP); Увеличить производительность, путём применения новой стратегии работы с конкуренцией ресурсов в ядре; Добавить несколько новых архитектур процессоров; Ввести новую модель тредов; Ввести новый планировщик; Добавить поддержку новых технологий, таких как управление питанием (это особенно важно для лэптопов); и наиболее критично, Не объявлять серии релизов, как STABLE до тех пор, пока все эти задачи не будут выполнены. Это привело к ситуации, когда между моментом временем, когда релиз из серии 4.X был объявлен, как STABLE и моментом, когда релиз из 5.X был объявлен, как STABLE прошло несколько лет. Это имело несколько нежелательных эффектов: Количество одновременных изменений групп характеристик сделало очень сложным изолирование одного набора изменений для слияния обратно в STABLE ветку; что означало, что пользователи, которые должны иметь определённые новые возможности (к примеру, использовать современное оборудование) работали путём адаптирования (к примеру) &os; 5.2.1 хотя он был известен, как релиз только для разработчиков, и независимо от того факта, что CURRENT релиз не совсем подходил для их нужд. В случаях, когда обратные слияния имели место, это поставило разработчиков в положение, когда они пытались поддерживать характеристики (feautures) на версии, которую они сами не использовали, как первичную платформу для разработки. Задержка во времени также значила, что когда 5.3 был наконец объявлен самым последним STABLE релизом, накопившееся количество изменений сделало процесс обновления очень болезненным. Более кратко, никто не был доволен результатом. Уроки, которые были получены: Новые старшие релизы должны иметь меньшее количество серьезных изменений характеристик и выпускаться более часто. В самой большой степени, серьезные изменения должны изолироваться друг от друга. (Это подразумевает, что некоторая разработка должна вестись вне основного дерева и может быть объединена с основным деревом только при условии, что это не нарушит другую одновременно продолжающуюся разработку.) Старшие релизы должны ориентироваться на последний срок по времени, а не на последний срок по количеству характеристик. Если какая-то возможность (характеристика) не закончена во время, то она должна быть убрана и оставлена до следующего старшего релиза. С помощью более частого выпуска меньшего количества изменений, также существует надежда, что меньше времени будет проводиться, пытаясь заниматься слиянием характеристик из HEAD обратно в последнюю STABLE версию (и тем самым пытаясь поддерживать эти характеристики более, чем в одной старшей версии); и далее, чем изменения более изолированы, тем риск появления новых ошибок намного меньше. Также, фокусируясь больше на последний срок по времени нежели по количеству характеристик, в итоге будет возможным для пользователей, разработчиков внешних приложений и самих разработчиков &os; иметь более лучший план на будущее. Эти соображения более, чем любой вид погони за основным номером релиза любой другой ОС, включают основную мотивацию для продолжения изменений в планировании. Улучшения целей планирования релизов Вот текущие цели в планировании для Проекта: Выпускать новый старший релиз каждые 18 месяцев; Выпускать новый младший релиз каждые 4 месяца; Обеспечивать предварительно собранные пакеты для последней младшей версии каждой старшей версии; Обеспечивать предварительно собранные пакеты для последнего релиза каждой старшей версии; Обеспечить обновления в безопасности и другие критические исправления ошибок для последних нескольких младших версий каждой старшей версии (ветки улучшений в безопасности, security branches). Из-за большого количества возможных комбинаций устанавливаемых версий, невозможно поддерживать каждую версию бессрочно; это от части из-за нехватки машинных ресурсов, но в основном из-за имеющихся усилий добровольцев. Заинтересованные читатели также могут посмотреть текущее расписание подготовки релизов и расписание веток + url="&url.base;/security/security.html#supported-branches">расписание веток улучшений в безопасности. Оба документа содержат более детальную информацию по предпосылкам и разумные обоснования этих решений. Как эти факторы повлияют на моё решение? Основные факторы, которые могут повлиять на ваше решение в выборе версии для установки: Какую степень стабильности требует ваша система? Сколько усилий вы хотите прикладывать для обновлений? Как долго вы планируйте оставаться на одной версии между обновлениями? Как важна безопасность для вашей системы? Будете ли вы устанавливаться из исходников или посредством двоичных файлов? Желаете ли вы помочь участвовать в процессе разработки &os;? Вот некоторые примерные инструкции для помощи вам в вашем решении: Если ваши нужды имеют краткосрочный характер, вы нуждаетесь в самой высокой степени стабильности, доступной на данный момент и не собираетесь обновлять большое количество ресурсов, то вы возможно захотите установить последний младший STABLE релиз и остаться с ним. В зависимости от ваших требований к безопасности, вы можете следить за изменениями в эту ветку, по мере их появления. Если ваши нужды имеют краткосрочный характер, и полнота возможностей или наилучшие уровни безопасности наиболее важны для вас, и вы желаете проводить время, обновляясь, вы можете использовать последнюю STABLE ветку. Если вы не планируете сразу промышленное использование, а хотите поработать с проблемами, и новый старший релиз появляется в следующие несколько месяцев, то вы можете поисследовать, установив эту ветку, чтобы помочь Проекту протестировать его, стабилизировать, сделать его самым лучшим релизом с уровнем качества выше среднего. Только если вы пожелаете устанавливаться из исходников и проводить время, занимаясь отладкой проблем с базовой системой и дальше передавать их посредством сообщений об ошибках и прослеживать список рассылки, в котором обсуждаются такие вопросы, вы можете рассмотреть для использования HEAD. Заключение Мы надеемся, что эта статья послужила полезной стартовой точкой в понимании модели разработки &os; и в решении того, какая версия наиболее подходит для ваших нужд.