From 4992525d31fbe818fffd4bc98ff5421572b9562a Mon Sep 17 00:00:00 2001 From: Vitaly Bogdanov Date: Tue, 25 Oct 2005 10:05:01 +0000 Subject: [PATCH] Add article version-guide in sync with original english revisions: version-guide/Makefile:1.3 version-guide/artcile.sgml:1.6 Makefile: Add to the build Obtained from: The FreeBSD Russian Documentation Project Approved by: marck(mentor) --- ru_RU.KOI8-R/articles/Makefile | 1 + ru_RU.KOI8-R/articles/version-guide/Makefile | 24 ++ .../articles/version-guide/article.sgml | 401 ++++++++++++++++++ 3 files changed, 426 insertions(+) create mode 100644 ru_RU.KOI8-R/articles/version-guide/Makefile create mode 100644 ru_RU.KOI8-R/articles/version-guide/article.sgml diff --git a/ru_RU.KOI8-R/articles/Makefile b/ru_RU.KOI8-R/articles/Makefile index c3ff3d9a10..e5b9e3b814 100644 --- a/ru_RU.KOI8-R/articles/Makefile +++ b/ru_RU.KOI8-R/articles/Makefile @@ -47,6 +47,7 @@ SUBDIR+= releng-packages SUBDIR+= solid-state #SUBDIR+= storage-devices #SUBDIR+= vinum +SUBDIR+= version-guide SUBDIR+= vm-design SUBDIR+= zip-drive diff --git a/ru_RU.KOI8-R/articles/version-guide/Makefile b/ru_RU.KOI8-R/articles/version-guide/Makefile new file mode 100644 index 0000000000..a20f636a50 --- /dev/null +++ b/ru_RU.KOI8-R/articles/version-guide/Makefile @@ -0,0 +1,24 @@ +# +# The FreeBSD Russian Documentation Project +# +# $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/version-guide/Makefile,v 1.1 2005/10/09 16:19:35 gad Exp $ +# $FreeBSD$ +# +# Original revision: 1.3 +# +# Article: FreeBSD Version Guide + +DOC?= article + +FORMATS?= html +WITH_ARTICLE_TOC?= YES + +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.sgml + +URL_RELPREFIX?= ../../../.. +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" diff --git a/ru_RU.KOI8-R/articles/version-guide/article.sgml b/ru_RU.KOI8-R/articles/version-guide/article.sgml new file mode 100644 index 0000000000..f04fbc45f8 --- /dev/null +++ b/ru_RU.KOI8-R/articles/version-guide/article.sgml @@ -0,0 +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). Разработка всегда продолжается + в так называемом тэге HEAD. + + + + Ветки + + Во время каждого релиза создается ветка + (к примеру, RELENG_5_4). Исходные файлы, названные + RELENG_5_4_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 + были очень мощными и включали: + + + + Обеспечить поддержку машин с симметричной мультипроцессорностью + (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). + + + + Из-за большого количества возможных комбинаций устанавливаемых + версий, невозможно поддерживать каждую версию бессрочно; это от + части из-за нехватки машинных ресурсов, но в основном из-за + имеющихся усилий добровольцев. + + Заинтересованные читатели также могут посмотреть текущее + расписание + подготовки релизов и расписание веток + улучшений в безопасности. Оба документа содержат более детальную + информацию по предпосылкам и разумные обоснования этих решений. + + + + Как эти факторы повлияют на моё решение? + + Основные факторы, которые могут повлиять на ваше решение + в выборе версии для установки: + + + + Какую степень стабильности требует ваша система? + + + + Сколько усилий вы хотите прикладывать для обновлений? + + + + Как долго вы планируйте оставаться на одной версии между + обновлениями? + + + + Как важна безопасность для вашей системы? + + + + Будете ли вы устанавливаться из исходников или посредством + двоичных файлов? + + + + Желаете ли вы помочь участвовать в процессе разработки &os;? + + + + Вот некоторые примерные инструкции для помощи вам в вашем решении: + + + + Если ваши нужды имеют краткосрочный характер, вы нуждаетесь в + самой высокой степени стабильности, доступной на данный момент и + не собираетесь обновлять большое количество ресурсов, то вы возможно + захотите установить последний младший STABLE релиз и + остаться с ним. В зависимости от ваших требований к безопасности, вы + можете следить за изменениями в эту ветку, по мере их появления. + + + + Если ваши нужды имеют краткосрочный характер, и полнота возможностей или + наилучшие уровни безопасности наиболее важны для вас, и вы желаете проводить + время, обновляясь, вы можете использовать последнюю + STABLE ветку. + + + + Если вы не планируете сразу промышленное использование, а хотите + поработать с проблемами, и новый старший релиз появляется в + следующие несколько месяцев, то вы можете поисследовать, установив + эту ветку, чтобы помочь Проекту протестировать его, стабилизировать, сделать + его самым лучшим релизом с уровнем качества выше среднего. + + + + Только если вы пожелаете устанавливаться из исходников и + проводить время, занимаясь отладкой проблем с базовой системой + и дальше передавать их посредством сообщений об ошибках и + прослеживать список рассылки, в котором обсуждаются такие + вопросы, вы можете рассмотреть для использования + HEAD. + + + + + + Заключение + + Мы надеемся, что эта статья послужила полезной стартовой точкой в + понимании модели разработки &os; и в решении того, какая версия наиболее + подходит для ваших нужд. + +